sanda search

sanda search finds rows by what their text says. The note on an invoice, the body of a support ticket, the description of a product: the paragraph is often where the reason for the number is, and a metric cannot read a paragraph.

It is included on Standard and Enterprise, and during a trial. You set it up and use it in the console under Intelligence · Vector search.

What it is for

The semantic fluid answers questions whose answer is a number. sanda search answers questions whose answer is a row:

• "Which invoices mention water damage?"
• "Find the tickets that sound like this one."
• "What do the notes say about the Ferndale site?"

It matches meaning as well as words, so a paraphrase finds a row that does not contain your words. It also matches words, so an exact reference such as an invoice number or a surname still finds its row.

Search returns rows and their keys, and never a total. To count or total what it found, take the keys and run a query with a condition on them. cherry does this for you. See search your records.

How it works

text columns of one table on your map
        |  cut into small pieces, turned into vectors
        v
an index in your warehouse
        ^
your search: matched by meaning and by words, then ranked together

1. You create an index over one table on your semantic map. You choose a key column that identifies each row, the text columns to search, and any columns to keep as filters. See create a search service.
2. sanda builds it. It cuts the text into small pieces, turns each piece into a list of numbers that stands for its meaning (a vector), and stores them. See build and refresh an index.
3. You search. Your words are turned into a vector the same way. sanda runs a search by meaning and a search by words, combines the two rankings, and shows each row once, with its best-matching piece.

An index is a table in your own warehouse, named after the index and beside your data. Only sanda writes to it. It counts towards your storage.

An index can only cover a table on your semantic map (one that has been accepted, not one sanda has only suggested), and only the columns you put there. That keeps an index inside what cherry may already read.

What leaves Australia

Your warehouse stays in Australia. cherry and sanda's other AI features already send small pieces of data to AI models (a question, a few sample values, the rows a query returns), as the privacy page sets out. Making an index is different in scale: it sends the text of whole columns, in bulk, to a third-party service outside Australia. So sanda search is off until a workspace owner switches it on.

• What is sent. The text of the columns you choose to index, in small pieces, and the text of each search you run, to a third-party service outside Australia that turns text into vectors. The service acts on sanda's instructions and does not keep the text.
• What comes back. A list of numbers per piece. They are stored in your own warehouse in Australia, beside the rows they came from.
• What is not sent. Your other columns, including the columns you keep as filters, your query results and your schema.

Only an owner can switch it on, because it is a decision about where your text may be processed. An admin cannot. The banner on the page sets out the same points and links to the privacy policy, which says who runs the model and where. The owner presses Switch sanda search on, and sanda records who agreed, when, and which version of the wording they agreed to.

To switch it off, the owner opens Search data processing & permissions at the foot of the page and presses Switch it off. Every index pauses, builds stop, and no more text is sent. Nothing already indexed is deleted, because the vectors are in your own warehouse. Switching it on again resumes where things stopped. An index's vectors are deleted when you remove the index.

Editions and limits

If your workspace moves to an edition without sanda search, it keeps its indexes and they stop answering. They answer again the moment you move back up. See editions.

What it costs

sanda search spends three things you already pay for.

• AI. Indexing and every search turn text into vectors, which is billed like any other AI call and counts towards your daily AI limit. You see an estimate before the first build. After that sanda only re-embeds rows whose text has changed.
• Compute. Building an index runs on your warehouse compute, and each build shows what it used.
• Storage. The index counts towards your warehouse storage.

Who does what

Where you can use it

• The console. The Vector search page.
• cherry. Ask about wording and cherry searches for you, once your workspace has an index with rows in it.
• AI assistants you connect over MCP. They can search with the permission to ask questions, and manage indexes with a separate search permission that only an owner or admin can grant. See MCP permissions.

Things to know

• There is no relevance cut-off. A search always returns the nearest rows, even for a question with no answer in the data. Read what comes back, and look at how each row matched.
• More text finds more. An index over one short column gives the search little to work with. Add the description or notes a reader would think of as part of the record.
• Filters are not searched. A column you keep as a filter narrows results but its words are not indexed. If you want to find a row by a category name, index that column as text too.