Sharding and Multi-Tenant

Scaling

Part of: Vector Databases & Production Search

Your index grows past what one machine's RAM can hold, and your single happy customer becomes five hundred companies who must never see each other's data. Both problems have the same shape: one giant pile of vectors needs to be split into many smaller, addressable pieces. The two tools for that are sharding (split for scale) and namespaces (split for isolation), and getting them right is the difference between a search that scales and a data-leak incident. What it is Sharding splits your vectors across multiple machines ( shards ) so the dataset no longer has to fit on one. A query either fans out to all shards and merges results, or, when you can, routes to just the shard that holds the relevant data. A namespace (or partition) is a logical boundary inside the store that isolates one tenant's vectors from another's, so a query for tenant A can never return tenant B's documents. Sharding is about capacity ; namespaces are about isolation . They often combine. How it works For multi-tenant routing, you assign each tenant's data to a partition and place inserts where they fit, respecting per-shard capacity: A query then carries its tenant id , the router maps it to the right partitio

Challenge: Multi-Tenant Shard Router