AnswersHybrid Search & Ranking

Can You Run Vector Search in SQL?

Q: Can you query vectors, run semantic search, and rank hybrid results with plain SQL over a Postgres connection, or do you need a separate vector-database client?

Yes, and there are two different ways to get there. A vector extension such as pgvector adds a vector column type and distance operators inside a relational database. A search engine that speaks the Postgres wire protocol, which is what TopK SQL is, exposes semantic, keyword, multi-vector, and hybrid scoring as ordinary SQL to any Postgres client. The difference is what the SQL can express. An extension gives you ORDER BY embedding query, one distance against one column. A search dialect treats scores as values: BM25, semantic similarity, and vector distance can be selected, weighted, and combined in a single ORDER BY expression, which is true hybrid ranking in one statement.

Can you query vectors, run semantic search, and rank hybrid results with plain SQL over a Postgres connection, or do you need a separate vector-database client?

4 min readJuly 2026

What does a vector extension give you?

pgvector adds a vector column type, distance operators, and ANN indexes to Postgres, so similarity search runs next to your relational data. You keep one system, transactional writes, and joins against the tables you already have. If your data already lives in Postgres, the corpus is modest, and a single distance ranking is all the search you need, the extension is the right choice, and you should take it.

Two ways to put vectors behind SQL.

Vector extension on Postgres

Relational engine

Vector column + distance operators

ORDER BY one distance

Right when data already lives there

Search engine speaking SQL

Search engine, Postgres protocol

Scores as SQL values

One hybrid ORDER BY expression

Right when ranking is the product

What does search-native SQL add?

Retrieval modes become scoring functions, and scores become ordinary values you can alias, filter, and combine. TopK SQL exposes each of its index types through one function:

Function	What it scores
`semantic_similarity(field, query)`	managed semantic search, embedded and reranked by the engine
`vector_distance(field, vector)`	dense or sparse ANN against your own embeddings
`multi_vector_distance(field, matrix)`	late-interaction MaxSim retrieval
`bm25_score()`	keyword relevance from `match_any` / `match_all` predicates

Tables are schemaless, so rows can carry undeclared fields that remain filterable, and the type system includes dense, sparse, multi-vector, and binary vector shapes natively. Indexes are declared inline on the column:

CREATE TABLE books (
    title          TEXT,
    published_year INTEGER,
    bio            TEXT             INDEX semantic_index(),
    embedding      f32_vector(768)  INDEX vector_index(metric = 'cosine')
);

The row multi_vector_distance deserves a second look: that is MaxSim, the scoring operator behind multi-vector retrieval, available as a SQL function.

How does hybrid ranking work in one statement?

Score each signal, alias it, and write the blend directly in ORDER BY:

SELECT _id, title,
    bm25_score() AS keyword_score,
    semantic_similarity(bio, 'an epic fantasy quest') AS semantic_score,
    vector_distance(embedding, '[...]'::f32_vector) AS vector_score
FROM books
WHERE match_any(bio, 'dragon wizard')
  AND published_year > 1950
ORDER BY
    0.2 * keyword_score +
    0.5 * semantic_score +
    0.3 * vector_score DESC
LIMIT 10;

As the TopK SQL announcement puts it, this is "hybrid search without multiple queries, client-side fusion, or reciprocal-rank fusion." It is the true-hybrid model expressed in SQL: every signal is scored inside one query, and the ranking is a single expression instead of a merge of separate result lists. Metadata folds into the same expression, so boost(semantic_score, published_year > 2010, 1.5) promotes recent books without a second pass.

What can connect to it?

Anything that talks to Postgres. The SQL layer implements the Postgres wire protocol in both simple and extended query modes, so psql, application drivers, ORMs, prepared statements, and dashboard tools connect without adapters. The connection is one line, with an API key as the password:

psql "host=elastica.sql.topk.io password=<api-key>"

Tables are inspectable through information_schema, and EXPLAIN shows the engine query your SQL was parsed into before it runs. The dialect is a thin mapping, and its parser is open source: the query you write in SQL and the same query in the Python SDK resolve to the same plan, so you choose the interface per surface, a notebook, a service, a BI dashboard, without changing what executes.

When is the extension the right choice?

Stay with pgvector when Postgres is already your source of truth, your corpus and query volume are modest, and search means one similarity ranking joined against relational data. Reach for search-native SQL when ranking is the product: when you need keyword, semantic, and multi-vector signals in one expression, engine-side embedding, and filters that stay fast at high selectivity, while keeping the Postgres tooling your team already uses.

TopK SQL ships today: the language overview covers the full dialect, and the announcement post (June 2026) walks through the design.