The noisy-neighbour problem is a multi-tenancy performance issue where one tenant’s heavy workload degrades the experience of other tenants sharing the same infrastructure. When many customers run on a common index and compute pool, a single tenant issuing expensive queries or holding a huge dataset can consume a disproportionate share of resources, slowing everyone else down.
The root cause is shared resources. In logically isolated designs — a shared index with tenant filtering, or many namespaces in one index — tenants compete for the same memory, CPU, and I/O. A large or busy tenant can crowd out smaller ones, causing unpredictable latency that varies with what neighbours happen to be doing, rather than with a tenant’s own usage.
Vector databases mitigate this in several ways: giving each tenant its own shard so their data and queries are isolated, decoupling resources in serverless architectures, or moving sensitive tenants to physical isolation. Predictable performance across tenants of very different sizes is a major engineering goal for multi-tenant systems, and how well a database avoids noisy neighbours is a key consideration for SaaS applications.