← Use cases

Run semantic search on embeddings from SQL

Semantic search doesn't have to mean another database. Keep embeddings in the workspace, build vector indexes, and run nearest-neighbor queries beside ordinary SQL. Similarity scores and relational filters stay in one place.

How it works

Step 1: Pick a table and text or vector column

Open the help articles table in our support KB and show the columns. I need to pick which field to use for meaning-based search.

Step 2: Create a vector index

Index article bodies for semantic (meaning-based) search, using cosine to compare how close two pieces of text are.

With --async, the build runs as a background job. Embedding and index materialization can take a while, so poll hotdata jobs until it's done.

Step 3: Search from the CLI with an embedding model

Ask in plain language how refunds work and return the ~10 help articles that best match the question by meaning.

Step 4: Same retrieval in SQL

Do that kind of search in SQL: closest matches first, with id, title, and how far each row is from the question. Limit to 10 rows.

When your ORDER BY … LIMIT lines up with HNSW and the index is ready, the planner can skip scanning the whole table. If not, distances still compute. They are just slower without the shortcut.

Who uses this

  • Support and docs search ranked by meaning, not just keywords.
  • Product catalogs mixing similarity with inventory, pricing, or eligibility filters.
  • Agents that need nearest-neighbor rows with distance metadata on the same path as other SQL.