Self-hosted vector database RFP questions

A credible partner asks for vector count, embedding dimensions, expected growth, query rate, filter selectivity and how many collections will exist before quoting any hardware. Each of these moves the result. Vector count and dimensions set the raw size of the vectors, while the index type, quantization and payload size set how much of that must sit in RAM. Query rate determines how many replicas and CPU cores you need to hold latency, and filter selectivity decides whether filtered searches stay fast on the chosen index. If a proposal names node sizes in the first meeting without these inputs, treat the number as a guess.

The baseline is vector count multiplied by dimensions multiplied by bytes per value, plus the payload and index overhead. For example, an illustrative collection of 10 million vectors at 768 dimensions stored as 32-bit floats needs about 30 GB for the raw vectors before index structures and payloads are added. Quantization reduces the bytes per value, and the partner should show the arithmetic for the exact configuration they propose, including payload indexes and the write-ahead log. Ask them to state which numbers are measured on your sample data and which are estimated from documentation.

HNSW gives fast, accurate search but keeps its graph structure in memory, so it suits collections that fit in RAM with headroom. IVF partitions vectors into clusters, which reduces the search space and can lower memory needs at some cost in recall. DiskANN-style indexes keep most of the data on disk, which trades latency for a smaller memory footprint and depends heavily on fast local storage. Milvus lists HNSW, IVF, FLAT, SCANN and DiskANN, and Qdrant and Weaviate offer their own index and quantization options. Ask the partner to benchmark recall and p95 latency on your data for two index choices, not only to name one.

No, not for the primary store of a vector engine such as Qdrant. Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on network file systems such as NFS or on object storage such as S3, with SSD or NVMe drives recommended. Milvus can use object storage such as MinIO, S3 or Azure Blob, but only as one component behind its coordinators and write-ahead log, not as a plain volume. Any partner who proposes NFS or S3 as the live store for a vector collection has not checked the engine's requirements, and you should ask for the reason in writing.

Replication multiplies stored data by the replication factor, so a factor of 2 roughly doubles storage, and a factor of 3 roughly triples it. In Qdrant distributed mode, collections are split into shards across nodes, and the replication factor adds copies on top of that. Weaviate replication is disabled by default and enabled per collection with a replication factor. The partner should show the sizing for each replica count, state the memory and disk per node, and explain how the number of copies affects the cost of extra nodes and backups. A proposal that sizes a single copy and ignores replication understates the bill.

Qdrant's distributed deployment documentation recommends at least three nodes for production clusters so quorum survives a node failure, and a shard count that is a multiple of the node count. Milvus distributed mode separates proxies, coordinators, workers, etcd, object storage and a write-ahead log, so the node count depends on each component's role and the availability target you set. Weaviate uses leaderless replication with tunable consistency levels, so the replica count and consistency choice together determine what a node loss costs. Ask the partner to name the failure they design for and show how the cluster behaves when one node is down during peak query load.

Be wary of a proposal that gives node counts without asking for dimensions or query rate, ignores replication or backup copies, or leaves out the memory needed for the index. Also be wary of a sizing that assumes all vectors fit in RAM without a measured test, or that proposes NFS or S3 for the live store. A sound proposal lists its assumptions, shows the storage arithmetic step by step, names the index and quantization settings, and includes a load test on a representative dataset before the production sizing is signed off. Ask for these artifacts in the written scope.

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so sizing is part of the written scope rather than a vendor quote. The engagement can cover collecting your vector count, dimensions and query patterns, producing the storage and replication arithmetic, testing index options on your data and documenting the node layout. Exact hours, timelines and fees are set only in the written scope after these inputs are agreed. Ask any partner, including DeployOpen, to state which sizing outputs are delivered and which tests run before infrastructure is ordered.

A credible partner stores the model identifier, model version, dimension count and the pipeline version as metadata on every vector or in a companion table, so each point can be traced to the model that created it. Ask to see the schema and a sample record. If the answer is that the team remembers which model was used, or that all vectors come from one model, treat that as a red flag. Vectors from two models are not comparable, so mixing them silently returns poor results without any error. Ask how the metadata is written during ingestion and whether it is checked at query time.

Changing the embedding model means re-embedding the whole corpus and rebuilding the collection, because vectors from different models cannot share an index. A good plan builds the new collection beside the old one, runs evaluation queries against both, then switches the application through an alias or configuration key. Re-embedding is recurring work tied to model upgrades, corpus growth and chunking changes, so it should be a documented, repeatable runbook rather than a one-off task. Ask what it costs in compute, how long a full rebuild takes at your corpus size, and whether the old collection is kept for rollback.

Each point should carry a stable source identifier, the chunk position, a content hash and the source system's version or last-modified time in its payload. With that, a change in a source record can be matched to every chunk derived from it. Ask how identifiers are generated, whether they survive re-chunking, and how the mapping is stored. If the partner cannot list every vector derived from one document within a short query, deletion and erasure requests will be unreliable.

Deletion should be driven by the source system's events or a scheduled sync that compares content hashes, then removes the affected points by identifier and filter. Ask whether the delete path removes the vector and the payload, and whether it is tested with a known document before go-live. Updates should be handled as delete then insert under a new version, not as an in-place edit that leaves stale chunks behind. A partner who describes deletion only as a manual clean-up step has not designed the path.

Yes, unless the backup policy accounts for it. Snapshots and backups copy the state at a point in time, so deleted vectors remain in them until those backups expire or are rewritten. Ask for the retention period for each backup tier, whether backups are encrypted with keys you control, and how a deletion request is recorded and proven against backup sets. Qdrant documents snapshots as a backup mechanism, so the partner should be able to show how snapshot retention is set and enforced. Confirm the answer for the specific engine you choose.

Keep a deletion log that records the request, the source identifiers, the number of points removed, the time and the operator or job that ran it, and then run a verification query that confirms zero matches remain in the live collection. Ask whether the log itself is retained separately from the vector data and for how long. Deletion evidence is what an assessor or data protection team will ask for, so it should be produced by the pipeline, not assembled by hand from memory.

Ask for a written test plan covering a model change dry run, a source update, a source deletion and a restore from a backup taken before the deletion. Effort depends on corpus size, the number of source systems, how many embedding models are in use and how often sources change. A fixed-scope engagement should state these items, the deliverables and the acceptance criteria in writing before work starts. You will need to supply access to source systems, a representative sample corpus, the approved embedding model and a decision on backup retention. DeployOpen does not publish prices, so ask for a quote from a written scope.

Yes, if the partner delivers the pipeline as code with a runbook, the metadata schema, the deletion job and the verification queries, and your team is trained to run them. Ask who owns the embedding job schedule, the credentials for source systems, and the on-call responsibility when a deletion job fails. Ongoing support, upgrades and continuous testing are available as retainers, which may suit teams that will not keep the specialist skills in-house. Confirm the handover list in the statement of work before accepting the engagement.

Watch memory use, disk use and disk I/O latency, query latency at the percentiles your users feel, indexing or write lag, replication health and error rates from the API. Memory and disk trends matter most because vector collections grow with every re-embedding run and every new document batch. Ask the partner to show which metrics their dashboards collect, how they are scraped and stored, and which thresholds trigger an alert. Confirm that audit logs of authenticated API operations are shipped to your log platform, since Qdrant documents JSON audit logging from v1.17.0 and other engines have their own logging options that you should verify in your environment.

Your on-call rota should name a primary and secondary responder for the database, with the partner's support hours and escalation path written next to it. Ask the partner who answers a page, how quickly they acknowledge a severity 1 event, and whether that commitment appears in a signed support schedule. Do not accept verbal assurances. If the answer is that the partner responds only during business hours, your own team must cover the rest, and that cost belongs in the scope discussion from the start.

A complete handover includes runbooks for restart, scaling, snapshot and restore, index rebuild, re-embedding, key rotation, certificate renewal and version upgrades, plus an architecture diagram and a list of every credential and where it is stored. Each runbook should name the exact commands or configuration keys used in your environment. Ask for a restore drill performed by your staff from those runbooks, not by the partner. Documentation that only the author can follow does not count as handover.

Your organization should hold root or cloud administrator access, all API admin keys, TLS private keys and the backup encryption keys, with access granted to named individuals through your identity provider where the platform supports it. Partner access should be time-limited and logged. Write this into the scope so that nothing depends on a partner engineer staying in place. A handover that leaves keys in a personal password manager or only in a partner's vault is a red flag.

Your staff need Linux and container operations, Kubernetes if you deploy there, storage administration for block devices, basic TLS and identity configuration, and enough database knowledge to read query and index performance. They also need someone who understands the embedding pipeline well enough to plan re-embedding after a model change. Ask the partner which of these skills they transfer through training or pairing, and what gaps remain. The effort to maintain the platform depends on how many engines, collections and environments you run, so ask for that count in the written scope.

A capacity review compares actual memory, disk and query load against the sizing model, projects growth from document intake and re-embedding plans, and recommends shard, node or storage changes before limits are reached. Ask how often the partner runs these reviews under a retainer and who presents the findings to your team. Your own team should also run a short review when a new collection or large import is planned. Confirm whether the reviews are included in the retainer or quoted separately.

A written retainer should list the monitoring hours, response times by severity, upgrade and patch windows, security updates, backup verification, capacity reviews and the number of change requests included. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements begin as fixed-scope work with scope, deliverables and timelines agreed in writing before work starts. Ask any partner to show what is excluded, such as major version migrations or new collections, and what those cost to add. A support offer without a written scope is not something you can hold a partner to.

Yes, if the handover produced runbooks, credentials under your control, tested restores and staff trained on upgrades. Open-source engines such as Qdrant (Apache-2.0), Milvus (Apache-2.0) and Weaviate's BSD-3-Clause code outside its enterprise directory can be run without a vendor contract, but enterprise features such as some Weaviate capabilities need a license key and Qdrant's enterprise operator is part of Qdrant Private Cloud. Confirm the license terms for every feature you plan to use before the partner leaves, and plan for the staff hours that continued operation requires.