Vector search

Vector search stores an embedding, a list of numbers produced by a model, next to an identifier and some metadata, then answers the question "what is closest to this" by approximate nearest neighbour. It is the right tool when the match is about meaning rather than characters: two support tickets describing the same fault in different words, a product a customer would like given one they already bought. It is the wrong tool for exact matching, and confusing the two is the most common way it goes bad.

How we use it

Objectify offers it as part of its AI surface. A tenant can generate embeddings for their records, index them, and query the index through the same REST API as everything else, gated to the paid tiers alongside the rest of the inference features. The embeddings come from the platform's own models, so Workers AI and the index sit in the same request path and there is no third-party hop in the middle.

Because Objectify is multi-tenant across ten sharded databases, the isolation question follows the vectors: an index is another place tenant data lives, and it has to be partitioned as carefully as the rows are. Namespaces do that job, and they have to be applied on write as well as read, since a query with a missing filter returns other people's neighbours rather than an error.

What it costs you

The index is not a database and does not behave like one. Dimensions and distance metric are fixed when you create it, so changing embedding model means building a new index and backfilling every record, which is a migration nobody schedules and everybody eventually does. Writes are not immediately queryable, so a user who has just saved something and searches for it may not find it, and the interface has to be honest about that.

Metadata filtering is limited compared with SQL. If your query is really "similar to this, but only from this customer, in the last 30 days, not archived", you will find yourself over-fetching neighbours and filtering in code, and the recall gets worse the tighter the filter. Every stored vector costs storage and every query costs a query, on top of the embedding call that produced the vector, so the cheap-looking feature has three meters running.

The failure we watch for is an index that is written on every create and never read on any path a user touches. It looks like a working feature in the stack list, it bills every month, and removing it changes nothing. Before an index goes in, we want to see the query that reads it.

When we would choose something else

Most search requests are keyword search wearing a costume. If people are looking for names, references, invoice numbers or error codes, a full-text index gives exact, explainable, instant results at no extra cost, and SQLite and D1 or PostgreSQL already have one. For large text corpora with faceting, ranking and aggregations, a dedicated engine such as OpenSearch is the better answer and sits under search and message streaming. We reach for vectors only when someone can describe a query that keyword matching genuinely cannot answer.