Why multi-tenant vector search is a security and contract problem for SaaS vendors
When a customer asks whether its embeddings are isolated, deletable and protected, a single shared index is not a defensible answer by default. For a SaaS vendor, every customer's vectors must be separable, provably deletable and covered by evidence, because the vectors are derived from that customer's documents and records and carry much of the same sensitivity. This differs from a single-organization deployment, where one trust boundary covers all the data. Here, the isolation model, the deletion path and the audit trail have to hold for each tenant separately, and they have to hold in the contract you sign, not only in your architecture diagram. The tenancy primitives differ by engine, so the choice follows from tenant count and isolation requirements. Qdrant separates data through collections and supports per-collection permissions through JWT-based access control. Weaviate offers multi-tenancy as a built-in feature and RBAC for custom roles. pgvector inherits PostgreSQL's schemas, roles and row-level security, which suits fewer tenants with strong relational controls. Confirm with each vendor how tenant count limits resource use, and test the behaviour with your own tenant model before you commit.
Qdrant needs hardening before any customer data is loaded. By default, self-deployed instances listen on all network interfaces and have no authentication configured, so the first control to set is authentication with API keys or JWT, followed by TLS for REST and gRPC. Treat this as a go or no-go check in your build pipeline, not a later clean-up item. Confirm in your own environment that the instance is unreachable without credentials before any tenant data is ingested. Customer security reviews will ask for exactly this evidence, so record the configuration and the test result as you go.
Which requirements a SaaS vector store must meet before customer data arrives
This table maps each requirement that customer security reviews and regulators tend to raise to its source, what it means for tenancy design, authentication and deletion, and the evidence to prepare. Read each row as a question to answer in design before the first customer embedding is written, not after the first questionnaire arrives.
| Requirement and source | What it asks for in vector store design | Evidence to prepare |
|---|---|---|
| Access control and monitoring (SOC 2 common criteria CC1 to CC9) | Every query path must enforce tenant identity, not just the application layer. Design per-tenant or per-collection permissions and log authenticated operations. | Access reviews, role definitions, audit log samples showing who queried which collection |
| Processor instructions (GDPR Article 28(3)) | Embeddings derived from customer data are processed on documented instructions only, including any transfer. Confirm where vectors and backups physically sit. | Data processing agreement terms, sub-processor list, data location map for vectors and snapshots |
| Security of processing (GDPR Article 32) | Encryption in transit and at rest, authentication on by default, and restore testing sized to the risk of customer records. | TLS configuration, key management records, restore test results |
| Switching and on-premises rights (EU Data Act, Articles 23, 25 and 50) | Customers must be able to move to another provider or on-premises infrastructure. Use export formats and collection layouts that do not lock vectors to one proprietary service. | Documented export procedure, tested reimport into a second engine, notice and transition timelines |
| Tenant isolation model | Choose collection, partition or payload-filter isolation per tenant tier. Stronger isolation limits blast radius but raises memory and operations cost per tenant. | Architecture decision record, isolation tests showing one tenant cannot retrieve another's points |
| Noisy neighbour controls | Limit per-tenant query rate and index build load so one large tenant cannot degrade latency for others. | Capacity plan, rate limit configuration, latency monitoring by tenant tier |
| Per-tenant deletion when contracts end | Deletion must cover vectors, payloads, snapshots and backups. Define how long backups hold deleted data and record each deletion. | Deletion runbook, deletion certificates or logs, backup expiry policy |
| Authentication and authorization model | Verify whether the engine supports API keys, OIDC and granular per-collection permissions. Confirm the default configuration is secured before go-live. | Configuration baseline, authentication test results, sample token scope documentation |
Collection, partition or tenant-level isolation: which model fits which tenant mix
Each customer gets its own collection, so vectors, indexes and access rules are separated at the collection boundary. This is the easiest model to explain to a security reviewer because a query for one tenant cannot touch another tenant's collection unless a credential is granted that reaches it. The cost is operational: every collection carries its own index, configuration, snapshot and deletion procedure, and a large tenant count multiplies those tasks. In Qdrant, per-collection JWT claims with read or write permissions let a service account be limited to specific collections, which is the concrete mechanism to test.
- Strongest logical separation: a credential scoped to one collection cannot read another tenant's points.
- Simple per-tenant deletion: dropping a collection removes that tenant's vectors, but confirm that snapshots and backups are also expunged on contract end.
- High operational overhead: provisioning, monitoring and upgrades scale with the number of collections.
- Resource fairness is harder: many small indexes can compete for memory on the same nodes, so noisy neighbour controls must be set deliberately.
- Best for: a bounded number of enterprise tenants with distinct compliance requirements.
Confirm with each engine's documentation how collection limits, memory overhead per collection and permission scoping behave at your expected tenant count.
All tenants share one collection, and each vector carries a tenant identifier that every query must filter on. This model gives the best density and the simplest operations for large numbers of small tenants. The risk is that isolation depends on the application always applying the filter, so a missed filter becomes a cross-tenant data exposure. Weaviate's multi-tenancy feature addresses part of this by giving each tenant its own shard within a collection, which separates storage and lets tenants be activated or offloaded independently. Confirm how that per-tenant shard model maps to your tenant count and query patterns.
- Highest density: many tenants share indexes and nodes, which lowers the base infrastructure per customer.
- Application-enforced isolation: a tenant filter on every query is a control that must be tested, not assumed.
- Weaviate tenant shards: per-tenant shards separate data physically inside one collection, so confirm the isolation guarantees it provides in your version.
- Noisy neighbour exposure: one heavy tenant can affect query latency for all others, so plan rate limits and resource monitoring per tenant.
- Best for: very high tenant counts with similar, modest data volumes and no contractual demand for dedicated storage.
Ask the vendor and your security reviewers how tenant filters are enforced, tested and logged.
Large or regulated tenants can receive a dedicated cluster, which separates compute, memory, storage and network from every other customer. This is the strongest isolation option and the one most often requested in enterprise security questionnaires, but it carries the highest cost because each cluster needs its own nodes, replicas, backups and monitoring. Qdrant's Hybrid Cloud and Private Cloud options describe dedicated or isolated deployments, and the commercial terms for those are set through Qdrant sales, so ask for the written scope rather than inferring it from the open-source documentation.
- Full resource and network separation: a dedicated cluster removes shared-memory contention and simplifies per-tenant data residency.
- Higher fixed cost: each cluster needs a minimum of nodes for availability, and distributed Qdrant docs recommend at least three nodes for production quorum.
- Separate lifecycle: upgrades, backups and deletion can be scheduled per tenant without affecting others.
- More places to secure: each cluster needs its own authentication, TLS, audit logging and monitoring evidence.
- Best for: large tenants, tenants with data residency demands, or tenants whose contracts require isolation.
Confirm the minimum node count, upgrade process and deletion evidence for each cluster before quoting a tenant tier.
Most SaaS vendors end up with a mix. The practical question is how many tenants you have, how large each one is, and which tenants have contractual or regulatory requirements that go beyond logical separation. Tenant count drives the operational cost of the first two models, while tenant size and regulatory exposure drive the case for dedicated clusters. A tiered design, where small tenants share a collection or tenant shard set and large or regulated tenants move to their own collection or cluster, is common, but the migration path between tiers must be designed in advance.
- Few large tenants: collection per tenant or dedicated clusters usually fit, because per-tenant overhead is spread over higher revenue.
- Many small tenants: shared collections with enforced tenant keys or tenant shards keep per-customer cost manageable.
- Mixed tiers: define the criteria for promotion between tiers, such as data volume, contract clauses or residency demands.
- Migration path: moving a tenant between models requires re-indexing or a verified export and import, which should be tested before it is promised.
- Illustrative example: a vendor with a few hundred enterprise customers and a large free tier might share collections for the free tier and use dedicated collections for paying enterprise accounts.
Write the tier criteria into the scope before implementation, and confirm how each engine handles tenant moves.
Which vector engines fit multi-tenant SaaS and why
Each engine isolates tenants differently, so the choice depends on how many tenants you serve, how strictly contracts separate their data, and how much operational work your team can carry. The cards below cover the two dedicated engines and PostgreSQL with pgvector, followed by the licence checks that apply to all three.
Qdrant for per-collection isolation
Qdrant is licensed under Apache-2.0, so you can host it for customers without a separate commercial licence for the engine. Its JWT-based access control grants read or write permissions per collection, which maps well to a collection-per-tenant or collection-per-tier model. Since v1.17.0, it also writes JSON audit logs of authenticated API operations. Check that your tenant count fits the collection model, because very large numbers of collections change memory and operational planning. Confirm the exact permission scopes with the current Qdrant security docs before you design token claims.
Qdrant distributed mode for production
Qdrant distributed mode uses Raft consensus for cluster topology and collection structure, splits collections into shards, and keeps extra copies through a replication factor. The Qdrant distributed deployment docs recommend at least three nodes for production so quorum survives a node failure. Replication roughly doubles storage at a factor of 2, which matters when every tenant's vectors are copied. Qdrant also documents that the community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so confirm which path your operations team can support.
Weaviate multi-tenancy and RBAC
Weaviate's README lists multi-tenancy as a built-in feature, and its user management API assigns custom roles and permissions through RBAC. Self-hosted instances support API key and OIDC authentication, which lets you connect tenant-facing identity to the engine. Its LICENSE file places code outside the wl directory under BSD-3-Clause. Code inside wl, along with enterprise features enabled by a license key, is governed by a separate Weaviate enterprise license, so confirm which features your product depends on before you commit to a design.
Weaviate enterprise license boundary
The license boundary is the check that most often gets missed. Some features are only available under the separate enterprise license, and those features are enabled by a license key. Before you ship a multi-tenant product, list every capability your tenant isolation relies on, then map each one to either the BSD-3-Clause code or the enterprise license. Ask your Weaviate contact in writing which terms apply when you host the software for customers, and keep that answer in your vendor file alongside the license text you reviewed.
PostgreSQL with pgvector and row-level security
pgvector adds vector columns to PostgreSQL, so tenant rows can sit under the row-level security policies, roles and backups you already operate. This suits SaaS products that already run PostgreSQL and have modest vector volumes. The trade-offs are index types, dimension limits and filtering behaviour under load, which you should test against your own data before you commit. Confirm the dimension and scale limits for your pgvector version, and confirm whether tenant filters are applied before or after approximate search so one tenant cannot see another's nearest neighbours.
Licence terms for hosted customer deployments
Most open-source licences allow internal use without restriction, but hosting software to serve customers can trigger conditions that internal use never does. Check whether the licence restricts providing the software as a managed service, whether it requires attribution or source disclosure, and whether any enterprise directories sit beside the core code. Record the licence version you ship and the features you use, and re-check at each upgrade. Your legal team should confirm the reading, because a licence that is acceptable for internal use may not be acceptable for a customer-facing service.
How to stop one tenant's query load from slowing every other tenant
Noisy neighbours appear when one tenant's indexing or query volume competes for the same memory, CPU and disk as everyone else. In a shared vector store, a large tenant that bulk-loads embeddings, rebuilds an index or sends a high rate of similarity queries can push latency up for small tenants on the same shards or nodes. Vector search is memory and disk heavy, so the contention usually shows first as slower queries, not as errors. Before choosing a layout, ask the engineering team which isolation model they plan to use (collection, partition or tenant-level) and how each one places tenants on shared nodes. The answer decides where contention can happen.
Sharding and replication are the main levers on the infrastructure side. In Qdrant distributed mode, collections are split into shards across nodes, and a replication factor keeps extra copies, which doubles storage at a factor of 2. Weaviate replication is disabled by default and is set per collection, so confirm which collections carry replicas and at what factor before you budget memory. Quantization reduces the memory each vector needs, which lowers pressure on nodes, but it can affect recall, so test it against your own queries. Per-tenant rate limits belong at the API gateway, where a single key or tenant can be throttled before its traffic reaches the database.
Measure contention per tenant, not only per cluster. Track query latency percentiles, request rate, indexing throughput and memory use for each tenant or collection, and set alerts on the tenants whose load grows fastest. Qdrant's JSON audit logging of authenticated API operations, added in v1.17.0, can help attribute requests to callers. Ask your implementation partner to load test a realistic large-tenant pattern against a small-tenant baseline on your chosen topology, and to document which tenants can be moved to dedicated nodes if the shared pool degrades.
Deleting one customer's vectors when a contract ends
This sequence removes one tenant's embeddings, payloads and derived records from live collections, snapshots and backups, and leaves a dated record that the deletion was completed. It also makes sure the customer can export its data before the exit, as the contract and the EU Data Act's switching rules expect. Run it under the processor instructions in your data processing agreement, so each step traces back to a documented instruction.
Confirm the exit instruction and export window
Before any deletion, confirm in writing what the customer has instructed under the processing terms, and whether they still need an export. Under the EU Data Act, providers of data processing services must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. Your contract team should map those dates to the exit timeline and record the instruction in the ticket. The step is done when the deletion request has a named owner, a written scope, and an agreed date after which deletion can proceed.
Export the tenant's vectors and payloads
Engineering exports the tenant's points, vectors and payloads in a format the customer can use with another provider or on-premises infrastructure. Use the migration guidance Qdrant publishes for moving data, and check that the export includes the embedding model name and dimension so the customer can re-embed or reuse vectors. Store the export in the agreed customer channel with restricted access. The step is done when the customer confirms receipt and the export checksum is recorded in the exit ticket.
Map every collection, point and payload for the tenant
Inventory where the tenant's data lives before deleting anything. List every collection that holds its vectors, including any shared collections where tenant identity is a payload field, and any secondary stores such as a relational table of document IDs, a cache, or a search index built from the same chunks. Confirm the tenant filter you will use and test it on a read-only query to count matching points. The step is done when the inventory lists each collection, the filter, and the expected point count, signed off by the engineer who owns the schema.
Delete live points and derived records
Delete the matching points from each live collection using the tenant filter, then remove the tenant's rows and cached entries in the surrounding stores. Run the deletion in a change window with the service account that has write permission on those collections only, and log the request IDs. Re-run the count query from the inventory step and confirm it returns zero in every collection. If a shared collection was used, confirm that other tenants' point counts did not change. The step is done when the post-deletion counts match the inventory and the logs are retained.
Remove the tenant from snapshots and backups
Live deletion does not remove the tenant's vectors from snapshots or backups. Use Qdrant's snapshot documentation to list the snapshots that cover each affected collection, and decide with your data owner whether to delete, rotate out or restore-then-purge them under your retention rules. Note that a restore from an older snapshot can bring deleted vectors back, so record the restore procedure and add a check that the tenant is absent after any restore. The step is done when every snapshot and backup set that held the tenant's data is listed, handled under a documented decision, and the restore check is written into the runbook.
Verify deletion across the environment
Run an independent check after the backup step, ideally by someone who did not perform the deletion. Query each live collection, restore-test copies and any staging or analytics replicas for the tenant identifier, and confirm no matches remain. Check that access logs and the deletion request logs show who acted and when. Confirm that the customer's exported data is still available until the agreed date. The step is done when the verification results are attached to the ticket and the reviewer signs off.
Record evidence and close the processor obligation
Compile a deletion record with the instruction, the export confirmation, the inventory, the request logs, the post-deletion counts, the snapshot decisions and the verification results. Give the customer a completion statement that describes what was deleted and what is retained only where law requires it. Keep the record under your compliance retention rules so it can be produced in a customer security review or an audit. The step is done when the record is filed, the customer has the completion statement, and the ticket is closed.
What customers' security reviews ask about vector data, and what produces the answer
This table maps the questions a customer's security review typically asks about vector data to the platform component or record that answers each one. Read it as a checklist for designing evidence before the first review arrives. The main takeaway is that most answers come from configuration, logs and deletion records you must keep on purpose, and DeployOpen prepares that evidence without issuing any attestation.
| Review question | What the reviewer wants to know | Component or record that produces the answer |
|---|---|---|
| Tenant isolation | Whether one customer's vectors can be returned to another customer's query | Collection, shard or tenant design documented in the architecture, plus access tests showing cross-tenant queries fail |
| Access control | Who can read or write each tenant's embeddings and with what scope | Qdrant admin and read-only API keys, and JWT tokens with per-collection read or write permissions |
| Encryption in transit | Whether traffic between applications and the vector store is protected | TLS configuration for REST and gRPC endpoints, with certificate records and a check that plaintext listeners are disabled |
| Audit logging | Whether authenticated operations on tenant data are recorded and retained | JSON audit logs of authenticated API operations, forwarded to the customer's log store with a stated retention period |
| Backup retention | How long copies of a tenant's vectors persist and who can restore them | Snapshot schedule and retention records, plus documented restore procedure and access controls on backup storage |
| Deletion evidence | Proof that a tenant's vectors were removed when the contract ended | Deletion job logs, point counts before and after, and a record of when snapshots and backups holding that data expire |
| Subprocessors and hosting location | Which parties and regions touch the data, including the embedding model | Hosting inventory naming the cloud account or data center, and the data flow diagram for the embedding model provider |
| Assurance report scope | Whether an independent SOC 2 report covers the vector store and its controls | A system description naming the vector store in scope, with Type 1 (design at a date) or Type 2 (operating effectiveness over a period) issued by an independent auditor |
What SaaS vendors ask before adding multi-tenant vector search
What drives the cost of multi-tenant vector search for a SaaS product?
The main drivers are tenant count, total vector count, embedding dimensions, replication factor and the people who run the cluster. Memory and disk grow with vectors and dimensions, and replicas multiply storage: the Qdrant distributed deployment docs note that a replication factor of 2 doubles storage. Engineering time to build tenant isolation, per-tenant deletion and monitoring is a one-time cost, while infrastructure, upgrades, backups and on-call recur every month. Ask any partner for a quote that separates one-time build work from recurring operations, and that states the vector count, dimensions and query rate it assumed.
How long does it take to build tenancy and per-tenant deletion?
The duration depends on how many isolation patterns you support, how many engines you run and whether deletion must reach snapshots and backups. Collection-per-tenant is simpler to reason about but multiplies operational objects, while payload-based or tenant-keyed designs need strict filter enforcement on every query. Deletion work includes removing points, rebuilding indexes where needed and proving that backups age out on a defined schedule. No duration can be stated from the supplied facts, so ask for a timeline in the written scope, with milestones for isolation tests, deletion tests and restore tests.
What must our engineers supply, and what does the partner cover?
Your engineers usually own the product decisions: the tenant model, how tenant identifiers are issued, which customer data becomes embeddings, and the contract terms that trigger deletion. The implementation partner typically covers cluster deployment, authentication and role setup, TLS, network exposure, backup and restore procedures, monitoring and the runbooks your on-call staff will use. Confirm the split in writing. Qdrant's security docs state that self-deployed instances listen on all interfaces with no authentication by default, so the hardening step must be explicit in scope.
Can our in-house team run multi-tenant vector search without a partner?
Yes, many teams can, provided they have engineers who already run stateful distributed systems and can own on-call for them. The skills gap usually sits in storage requirements, consensus and quorum, backup consistency and security configuration. Qdrant requires block-level storage and cannot run on NFS or S3, and its distributed mode recommends at least three nodes for production so quorum survives a node failure. Weaviate's replication is disabled by default and set per collection. Assess your team against those specifics before deciding, and treat a partner as an option for the build, the hardening or the first year of operations.
How do customers' security reviews change the vector database design?
Enterprise customers typically ask where vectors are stored, who can query them, how tenant boundaries are enforced, whether access is logged, and how deletion is evidenced. Answers should map to specific controls: per-collection or per-tenant permissions, TLS for REST and gRPC, JSON audit logging of authenticated operations (available in Qdrant since v1.17.0), and backup retention rules that match deletion promises. SOC 2 scope depends on the system description and the trust services criteria you select, so define the vector store inside that boundary early. DeployOpen prepares systems and evidence for these reviews but does not issue audit reports or certifications.
How do we move to another engine or back to our own infrastructure later?
Plan the exit from day one. The EU Data Act, Regulation (EU) 2023/2854, requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period (Articles 23, 25 and 50). From 12 January 2027, providers may not impose switching charges. For your own design, keep embeddings reproducible from source records, store the embedding model version with each collection, and test exports and restores into a second engine. Ask any partner how they would export vectors and payloads and how they would verify the copy.
What licence terms should a SaaS vendor check before building on an engine?
Check the licence of every engine and every add-on, because terms differ and some restrict offering the software as a service. Qdrant is listed as Apache-2.0 in its GitHub repository. Weaviate's LICENSE file places code outside the repository's "wl" directory under BSD-3-Clause, while code inside "wl" requires a separate enterprise license and is enabled by a license key. Confirm which features your design depends on, such as multi-tenancy or RBAC, and whether they sit under the enterprise terms. Have your legal team review the final stack before you commit to a tenancy model.
Questions to ask an implementation partner before they design tenancy
Start with the isolation test, because a design diagram proves little on its own. Ask the partner to show how they would demonstrate that tenant A cannot read, search, count or infer vectors belonging to tenant B, and which test cases they would run against the chosen store, whether that is a per-tenant collection, a partition key with payload filtering, or a native multi-tenancy feature. Ask who writes those tests, whether they run in CI on every change, and what happens when a query omits the tenant filter. The answer should name the specific mechanism, not just say the data is isolated.
Ask how they will harden the installation before any tenant data arrives. Qdrant's security documentation states that self-deployed instances listen on all interfaces and have no authentication configured by default, and self-hosted Weaviate offers API key, OIDC and anonymous access, with anonymous access discouraged outside development. Ask which of these they enable, how they scope per-collection read and write permissions, whether TLS covers both REST and gRPC, and where JSON audit logs of authenticated operations are shipped. Also ask how they size shared versus dedicated clusters, including how they would detect a noisy tenant that drives memory or query load for everyone else, and what evidence they keep when a tenant moves to a dedicated node.
Ask how they prove deletion, including the parts that people forget. A per-tenant deletion request should cover live points and payloads, snapshots, replicas, backups, logs that contain query text and any re-embedding staging data. Ask for the exact procedure, the verification query or count they run afterwards, and how they handle backups that cannot be edited, including the retention window and whether a restored backup could bring a deleted tenant back. On re-embedding, ask how a change of embedding model is run per tenant, how old and new vectors are kept apart, and how the cut-over avoids mixing dimensions in one collection. Finally, ask what evidence they hand over for a customer security review: configuration baselines, access reviews, test results and sample deletion records, and which of those are produced by the partner and which must come from your own team.
How a multi-tenant vector rollout runs in phases
The sequence moves a SaaS vendor from a tenancy decision to a production vector service where isolation and deletion have been tested before any customer data is loaded. Each phase closes with a named artifact that the next phase depends on.
Scope the tenancy model and review licences
The vendor's product owner, architect and legal counsel agree how tenants map to storage units, whether isolation is at collection, partition or tenant-level, and how many tenants and embeddings each tier will hold. In the same phase, the team reviews the licence of every candidate engine and any add-on, including whether the license terms permit the planned hosting model and customer-facing use. The output is a tenancy design record covering isolation level, expected tenant sizes, the licence review and the open questions that must be closed before build. The phase is done when the design record is signed off by engineering and legal.
Build the hardened self-hosted environment
The platform engineering team deploys the chosen engine into the vendor's own cloud accounts or data centers, on block storage with SSD or NVMe drives rather than network file systems or object storage. Qdrant ships without authentication by default and listens on all interfaces, so the team must configure API keys or role-based access, TLS for REST and gRPC, and network policies before any service can reach it. Weaviate similarly requires API key or OIDC authentication with anonymous access disabled. The output is a hardened baseline configuration, a deployment record and a checklist showing each control was verified on the running system.
Wire per-tenant access and audit logging
Engineers map each tenant to its collection, partition or tenant object and bind the application's service identities to the minimum permissions needed. Where the engine supports per-collection permissions through JWT or custom roles, the team uses them so a compromised application credential cannot read another tenant's vectors. Audit logging of authenticated operations is enabled and shipped to the vendor's central log store. The output is an access matrix and a logging configuration that the security team has reviewed, which will later serve as evidence in customer security reviews.
Prove isolation and deletion with tests
QA and security engineers write automated tests that attempt cross-tenant reads, writes and searches using valid credentials for one tenant against another tenant's data, and confirm that filters cannot be bypassed through query parameters. They also test that deleting one tenant removes its points, payloads and index entries, and they check whether snapshots and backups still hold that tenant's data. The output is a set of isolation test results, a deletion test report and a deletion runbook that states how snapshot and backup retention affects the deletion claim. The phase is done when every failing case is fixed or formally accepted by the vendor's risk owner.
Measure noisy neighbour behaviour under load
Performance engineers load representative tenants of differing sizes and query rates to see how one heavy tenant affects latency for others. They confirm whether the chosen sharding, replication factor and resource limits keep tail latency acceptable, and they document the per-tenant quotas or rate limits that the application layer will enforce. Qdrant distributed mode recommends at least three nodes for production so quorum survives a node failure, and that node count should be checked against the load plan. The output is a load test report and a capacity model that links tenant count and vector count to memory and node needs.
Pilot with one or two tenants
The team onboards one or two willing customers under a written pilot agreement, loading only their data and monitoring access logs, error rates and query latency daily. Customer-facing teams confirm that the deletion process works when a pilot tenant asks to leave, using the runbook from the testing phase. The team also records any gaps between what the security review questionnaire asks and what the environment can evidence. The output is a pilot report listing defects, evidence gaps and changes to the runbook, approved by the product and security owners before wider rollout.
Onboard tenants and operate the service
The team moves remaining tenants onto the platform in batches, with each batch gated by the isolation checks and capacity thresholds established earlier. Operations takes on upgrades, backup restore tests, certificate renewal, key rotation and monitoring, and it keeps the security evidence pack current for customer reviews. The output is a live service with a recurring operations calendar, a current evidence pack and a change log that shows each tenant's onboarding and any deletion carried out under the runbook. Ongoing support can be handled by the vendor's own team or a retained partner, which should be agreed in writing before go-live.
Deployment patterns for multi-tenant vector search
Most SaaS vendors choose among three placements for customer embeddings: one shared cluster, a pooled cluster with dedicated collections for larger tenants, or a separate deployment per customer. Each trades isolation against cost and operational load, and the right mix usually depends on which tenants carry contractual or regulatory isolation requirements.
Shared cluster with tenant keys
All tenants share one collection and one cluster, and every point carries a tenant identifier that every query must filter on. This is the cheapest pattern to run and the easiest to scale, but isolation depends entirely on the application enforcing the filter. Check that the tenant filter is applied server-side or through a single data access layer, that no admin or export path skips it, and that a test suite proves one tenant cannot retrieve another tenant's neighbours. Weaviate lists multi-tenancy as a built-in feature, and Qdrant supports per-collection read and write permissions through JWT-based access control, which helps with separation at the access layer.
Pooled cluster with dedicated collections
Each tenant gets its own collection inside a shared cluster, which gives a hard boundary for queries, permissions and deletion without paying for a separate cluster per customer. Larger tenants can be moved to their own collection first, which limits the noisy-neighbour effect of one heavy customer on query latency. Ask how the vendor manages collection count, index build time per collection and memory overhead, since many small collections can cost more in memory than a few large ones. Confirm that per-collection permissions and per-collection backups are supported in the chosen engine and version before relying on them.
Dedicated deployments for regulated accounts
Large or regulated customers may require their own vector database instance, sometimes in their own cloud account or data center. This gives the strongest isolation and simplifies per-customer deletion and key management, but multiplies the upgrade, backup, monitoring and on-call work by the number of deployments. Qdrant Hybrid Cloud runs managed clusters on the customer's infrastructure, and Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment. Both are priced through Qdrant sales, so confirm the exact scope, support terms and included features in writing before comparing them with a self-managed deployment.
Tenant-scoped deletion at contract end
When a contract ends, the vendor must remove that customer's vectors, payloads, backups and snapshots within the terms agreed with the customer. Shared clusters make this a filtered delete that must be verified, while dedicated collections or deployments make it a collection drop or instance decommission. Document how deletion propagates to replicas, snapshots and backup archives, and how long those copies persist. Ask for evidence that deletion was completed, such as a logged delete operation and a post-deletion query showing zero matches for that tenant.
Authentication and audit per tenant
Customer security reviews usually ask who can read a tenant's vectors, how that access is authenticated and whether API operations are logged with the tenant involved. Qdrant supports admin and read-only API keys, TLS for REST and gRPC, and JSON audit logging of authenticated API operations, but by default a self-deployed instance listens on all interfaces without authentication. Weaviate supports API key and OIDC authentication with RBAC. Confirm that service accounts are scoped per tenant and that audit logs record the tenant or collection, not only the service account.
Noisy neighbour and capacity limits
One tenant with a very large collection or a high query rate can slow search for others on a shared cluster, and memory is usually the first limit reached. Plan per-tenant quotas on collection size, vector count and request rate, and test a load profile for the largest tenant before onboarding it. Moving heavy tenants to dedicated collections or deployments is the usual remedy, so the migration path should be designed early. Ask the engine vendor or partner how index memory grows with dimension and vector count, and how a tenant can be moved without downtime.
How DeployOpen scopes, builds and supports multi-tenant vector search
DeployOpen's work starts with a written scope that names the engine, the isolation model and the boundary DeployOpen is responsible for. Before any build, we agree which tenancy pattern the SaaS product needs (collection per tenant, shared collection with a tenant key, or a dedicated deployment for large or regulated customers), how the application passes tenant identity to the vector store, and who owns each runbook. We then self-host the chosen engine, such as Qdrant, Weaviate or PostgreSQL with pgvector, in the client's own cloud account or data center. Hardening covers the defaults that matter most: Qdrant ships without authentication and listens on all interfaces, so API keys or JWT-based per-collection permissions, TLS, network policies and audit logging are configured and tested before any tenant data is loaded. Where the engine supports RBAC or per-collection roles, we map them to the service accounts the application actually uses.
The integration work sits between the SaaS application and the vector store. DeployOpen builds the ingestion path that writes embeddings with the tenant identifier attached, the query path that applies tenant filters on every request, and the deletion runbook that removes a tenant's points, payloads, snapshots and backups when a contract ends. The deletion runbook needs an explicit decision on backup retention, because a snapshot that still holds a departed customer's vectors is a data-handling problem of its own. We also run security testing against the tenancy boundary itself, including attempts to retrieve one tenant's vectors with another tenant's credentials or through a filter that is omitted or malformed. Results are documented so the client can show what was tested and what was fixed.
DeployOpen prepares the configuration, runbooks, test records and monitoring evidence that a customer's security review or an assessment by an independent auditor may request, such as access control settings, audit log samples and restore test results. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered. Before signing, ask the partner to show how they will test tenant isolation, how they will prove deletion, and which parts of the evidence they produce versus which parts your own team or auditor must own.
