collection.query(
select(
"_id",
score=fn.multi_vector_distance("vectors", user_vecs),
)
.filter(field("market") == "us")
.sort(field("score") * field("quality"), asc=False)
.limit(200)
)Your recommender never stops evolving. Candidate retrieval has to keep up.
Most of the hard work in RecSys sits above retrieval: interaction logs, feature pipelines, representation learning, ranking and policy models, and experiments. Still, the layer that looks simplest from the outside can become the bottleneck: candidate generation starts limiting everything above it. If the right items never reach the pool, no ranking model can recover them.
Represent
User, session, and item embeddings
Retrieve
Fresh candidates with product filters
Rank
Relevance, quality, and policy
Serve
Feeds, recommendations, and discovery
TopK is built for that reality: one retrieval layer flexible enough for the representations, writes, filters, scale, and operational access your product will need next. Teams can keep iterating on surfaces without turning each launch into another retrieval chore or infrastructure detour:
One retrieval layer for every surface
Representation flexibility
TopK supports the representation and retrieval patterns production systems already use: dense vectors, sparse vectors, keywords, and metadata filters in one layer. TopK is ready for the next paradigm: late-interaction retrieval. Bring your own late-interaction representations with multi_vector_index and SMVE, or use managed semantic_index for batteries-included retrieval over text data with managed multi-vector inference.
Online writes without rebuilds
TopK can ingest 70 MB/s per partition with writes becoming queryable without index rebuild lag. For 1024-dimensional fp8 vectors, that is roughly 70,000 vectors per second per partition.
Product-aware retrieval
Filters are evaluated inside retrieval, so each surface can bring its own category, price, region, recency, inventory, policy, experiment, or _id IN (...) constraints without separate indexes, recall regressions, or manual retuning.
Room to grow
Reuse the same representations as new feeds, shelves, pages, and experiments launch. Scale partitions to 1B+ items and use unlimited partitions per collection for native multi-tenancy or logical decomposition of huge catalogs. Add read replicas for horizontal serving throughput.
Retrieval you can inspect
Your stakeholders want to see inside the recommender. TopK SQL speaks the Postgres wire protocol, so engineers, analysts, content teams, and internal dashboards can inspect and observe production retrieval behavior through notebooks and standard SQL tooling.
New items should not wait on the write path or index rebuilds
Recommender systems are write-heavy: new inventory, availability changes, metadata updates, and refreshed model outputs must reach serving quickly. After a model processes a new item, it can still wait in the write queue or behind an index rebuild. TopK handles both: it can ingest 70 MB/s per partition, roughly 70,000 1024-dimensional fp8 vectors per second per partition, and writes become available for retrieval without waiting for the next rebuild.
Multi-vector retrieval that can serve online
Late interaction is expressive because it does more work: MaxSim compares query vectors against item vectors and aggregates the best matches. TopK does not brute-force that across the corpus. Managed semantic_index and bring-your-own representations in multi_vector_index both use sparse multi-vector encoding as a fast first-stage retriever, then refine candidates with quantized MaxSim reranking over the original multi-vector representations.
In the production semantic_index benchmark, TopK measured the whole path end-to-end: ingest, embedding inference, indexing, concurrent queries, and retrieval quality. On a sustained 10M-scale run, the system served multi-vector retrieval at 124.8 ms p99 latency while sustaining 176.5 QPS per replica set, with 1.2s index lag. For storage and serving architecture details, see the architecture write-up.
Same representations, many surfaces
Teams rarely retrain representation models for every new product surface or experiment. They change where candidates appear, what is eligible, and which product signals get boosted. TopK lets the same user, session, and item representations power feeds, rails, profile pages, notifications, and experiments without building a new retrieval path each time.
Home feed
Match items to this user
Score every item by multi-vector distance to the user's vectors.
Keep only what's eligible
Drop anything not available in the current market.
Order with a quality boost
Sort by score × quality and return the top 200.
for the Home feed, find the items most similar to this user, keep only the ones available in their market, then rank by relevance boosted by quality — returning the top 200.
Starting a new recommendation surface without a trained representation model? semantic_index gives you managed multi-vector inference from listing descriptions, with room to replace or augment it with your own model later.
Surface-aware retrieval means speedup
Production RecSys rarely searches the whole catalog. It asks for eligible candidates under product, policy, inventory, experiment, and personalization rules. In many ANN stacks, the filter is independent of the geometry the index was built on, so teams must overfetch and still risk recall cliffs.
TopK makes eligibility part of the retrieval query: filters run before candidates are returned, so each surface can add rules without separate indexes or manual retuning.
Unfiltered38.3 ms
38.3 ms
10% eligible33.0 ms
33.0 ms
1% eligible25.0 ms
25.0 ms
p99 latency on a 10M metadata-filter benchmark. recall@10 stays above 95%.
Your team should spend its time above retrieval: on representation learning, ranking and policy models, experiments, and product logic. TopK gives you candidate retrieval you can rely on, scale to high-traffic scenarios, and reuse across placements without maintaining indexes or losing candidates under filters.