Vector database
Large datasets are hard for an AI agent to use well: it can't read a whole space, and keyword search misses anything phrased differently. Boost.space's vector database solves this. It turns the text in your records into embeddings — numeric representations of meaning — so an agent can retrieve the most relevant records by meaning, not exact words.
The result: agents (and your own code) get lean, on-point context from even a huge space — exactly what retrieval-augmented generation (RAG) needs — instead of dumping thousands of rows into a prompt.
Why it matters
- Search by meaning. "Unhappy enterprise customers" finds the right records even if none contain those words.
- Context at scale. An agent pulls the handful of records that matter before it acts, so answers are grounded in your data and stay within the context window.
- Same permissions. Vector search is scoped to a space and the acting user's access — an agent only ever retrieves what that user can see.
- Find the unusual, too. Surface outliers — records that don't fit a description — for anomaly detection and data-quality review.
Enabling it
The vector database is an Enterprise feature — contact support to unlock it. Once it's available, you turn it on where the data lives:
In a space's settings, switch on Vectorization ("Embed this space's records so AI and search match them by meaning"). That is the whole setup — there is nothing to pick field by field.
What gets embedded. Every text and rich text field on the records in that space, and only those. Numbers, dates, checkboxes, and selection fields are left out: a date has no meaning to compare, so embedding one would cost tokens and return noise. Rich text is stripped to its prose before it is embedded, so markup never competes with the actual words. Only records in custom modules are embedded.
The scope you control is therefore the space, not the field. Switch vectorization on where the text worth searching lives, and leave it off elsewhere.
Keeping it current needs no work at all. Saving a text value embeds it as part of the same write, so a record is searchable the moment it is saved — no queue to watch, no nightly job, no re-indexing step. It adds a small delay to writes in a vectorized space, and nothing else.
Using it
Once a space is vectorized, three operations are available over the REST API:
| Operation | What it does | Use it for | Over MCP |
|---|---|---|---|
| Similar | The records most semantically similar to a query, ranked by relevance. | Semantic search, "find records like this", RAG retrieval | yes |
| Outliers | The records furthest from a query. | Anomaly detection, data-quality review | yes |
| Context | A compact, lean list of the most relevant records — trimmed field values, built for agents that need context before acting. | Grounding an agent's answer on your data | REST only |
All three are scoped to one space, accept a natural-language query, and can be pre-filtered by a filter or a saved segment first. You can also set a relevance threshold to keep only strong matches.
What people actually use it for
Three operations do not sound like much until you see what they replace. These are patterns in real use, not hypotheticals.
Agents finding the right records. The most common use by a distance, and the one that makes everything else an agent does possible. An agent asked to "look at our unhappy enterprise customers" has no keyword to search for — "unhappy" appears in none of your fields. Semantic search is how it finds the records a human would have picked, which is why a vectorized space is worth so much more to an agent than a plain one.
Categorising new records from the ones you already sorted. A supplier sends products with no categories. Instead of writing rules, search your existing catalogue for the records most similar to each new one and read the categories and tags off the matches. Your own past decisions become the classifier, so it already knows your taxonomy, your naming, and your edge cases — and it gets better every time somebody categorises something by hand.
Finding the prospects who look like your buyers. Take the customers who actually bought as the description of what a good customer looks like, then search the rest of your database for the records most similar to them. What comes back is a ranked list of prospects that resemble people who already said yes — a far better basis for deciding whether to spend on a campaign than demographics you guessed at.
Finding the records that are quietly broken. This one runs the search backwards. Query with a description of your best records and ask for the outliers — the ones furthest from it. Poor descriptions, thin data, mistyped entries, and quietly wrong records all surface together, because what they have in common is not resembling anything good. It is the fastest way to build a data-quality worklist without writing a single validation rule. Save it as a segment and it stays a standing queue.
Every one of these gets sharper with a filter in front of it. Categorise within one product range, look for lookalikes within one region, hunt outliers within one catalogue — narrower candidates, better ranking, and for outliers, dramatically less work.
Filter first, then search
Narrow the records with a real filter, then let semantic search rank what is left. This is the one habit that decides whether semantic search feels sharp or vague, and it is worth building into every query you or your agents write.
It works because that is genuinely the order things happen: the filter resolves the candidate records first, and only those are ranked by meaning. If the filter matches nothing, no embedding call is made at all. So a filter is not a post-processing step you bolt on — it decides what the search is even looking at.
Two things follow:
- Accuracy. "Enterprise customers unhappy about onboarding" searched across every record will surface whatever is loosely similar anywhere. Filter to the enterprise segment first and the same query ranks only records that were already the right kind of record.
- Speed, especially for outliers. Similarity search is index-backed; outliers are not — finding what is least similar means scanning the whole candidate set, because an index built to find near neighbours cannot shortcut to far ones. On a large space, filtering first is not a nicety for outliers, it is the difference between a usable query and a slow one.
Over MCP, this is the semantic search an agent reaches for when it needs the right context from a large space without reading all of it. Tell your agents the same rule: filter, then rank. See what an agent can do.
Next
- Connect via MCP — let an agent query your data
- API reference · AI overview
