Use Vectorize in a real application path
Vectorize stores embeddings in Cloudflare-managed indexes for similarity search from Workers.
A real Vectorize application path with config and runtime code kept side by side.
That is enough to show the binding shape, the worker contract, and the Devflare remote gate without dragging in a whole retrieval stack on page one.
- Config focus
- Explicit index naming
- Runtime shape
- Upsert one vector and query it back
- Best use
- Search prototypes and embedding-backed retrieval endpoints
Start by wiring the binding clearly in config
Minimal Vectorize config
Build the application flow around the binding
Treat this as the app-level Vectorize path: the route, event handler, or service module receives a real request and uses the binding to do useful work.
Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.
- Keep the embedding dimension explicit and consistent with the actual index you created.
- If you later split write and read into separate routes, this same example still teaches the core binding path.
A tiny write-and-query route
Keep production boundaries visible
- Config focus: Explicit index naming.
- Runtime shape: Upsert one vector and query it back.
- Best use: Search prototypes and embedding-backed retrieval endpoints.
Previous
Testing Vectorize
The right Vectorize tests are targeted remote checks: a small insert or query, a clear skip condition, and a real index behind the binding.
Next
Hyperdrive
Hyperdrive is modeled in Devflare config, compile flows, local Miniflare wiring, and pure tests through explicit local connection strings.