Why a PostgreSQL estate changes the vector search decision
If your organization already runs PostgreSQL for its business data, and its backups, high availability and access control live there, then pgvector on the existing estate is usually the lowest-friction place to start with embeddings, but only inside its stated limits. pgvector supports vector columns up to 16,000 dimensions, indexes vector columns only up to 2,000 dimensions, and with approximate indexes applies filters after the index is scanned. Those three limits decide whether the first build holds, so check them against your embedding model and your access rules before you commit.
The real question is not which product has the best search but whether you want to inherit an operating model or take on a new stateful system. On a PostgreSQL estate, your team already has backup procedures, replication, monitoring, upgrade practice and database roles, and the vectors sit beside the source rows they were derived from, which simplifies deletion when a source record changes. A dedicated store such as Qdrant adds its own storage requirements, authentication configuration, backup method and upgrade cycle, and it needs its own operators. The cost of that second system is paid in people as much as in infrastructure.
Our working recommendation is pgvector first, and a dedicated vector store only when measured needs exceed what the estate can deliver. Measure recall, query latency and index build time on a representative copy of your data, and confirm how your PostgreSQL major version and extension versions will be upgraded. If filtered queries return too few results or the collection outgrows memory on your existing nodes, that is the signal to plan a split. Ask your implementation partner to show those measurements, not only a feature comparison.
Requirements that decide between pgvector and a dedicated store
This table compares the requirements that most often decide whether pgvector on an existing PostgreSQL estate is enough or a dedicated vector store is needed. Read each row as a build question: what the limit or behaviour means for your design, and what you must confirm in your own environment before committing.
| Requirement | What it means for the build | What to confirm in your environment |
|---|---|---|
| Vector dimensions | pgvector stores vector and halfvec up to 16,000 dimensions, but indexes vector columns only up to 2,000 dimensions. Embedding models above that ceiling need a reduced dimension, a halfvec index or a different store. | Dimension count of your chosen embedding model, whether you can use a halfvec index, and whether the model supports dimension reduction without retrieval quality loss. |
| Filtering with approximate indexes | With HNSW or IVFFlat, filters apply after the index scan, so selective metadata filters can return fewer rows than requested. Iterative index scans can fetch more results, but they add query cost that must be tested. | Query patterns that combine tenant, permission or date filters with vector search, and measured recall and latency under those filters on realistic data volumes. |
| Backup and point-in-time recovery | Vectors live in the same database as relational data, so existing continuous archiving and point-in-time recovery usually cover them. Restores must be tested for the vector tables, and derived vectors may need to be rebuilt from source rather than restored. | Whether your current backup tooling archives WAL, the restore time you have tested for the database, and whether embeddings are treated as backed-up data or regenerable data. |
| High availability and failover | PostgreSQL provides hot standbys and synchronous or asynchronous replication, but it does not detect primary failure or promote a standby. Automatic failover depends on external tooling that your team must select, operate and test. | The failover tool already in use on your PostgreSQL estate, who operates it, how connection routing is handled, and the recovery behaviour of your current cluster. |
| PostgreSQL major version support | PostgreSQL 14 is supported until November 12, 2026, and 15 until November 11, 2027. Each major version has five years of support, so a vector workload may need a major upgrade on the same schedule as the rest of the database. | The major version you run, its end-of-support date, the pgvector version compatible with it (pgvector supports PostgreSQL 13 and later), and whether your upgrade path is pg_upgrade or logical replication. |
| Authentication and access control | PostgreSQL offers password (SCRAM), GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth authentication. Row-level permissions on vector tables can reuse the identity model already in place, which often simplifies per-user or per-tenant access. | Whether your identity provider can integrate through one of the supported methods, whether SCRAM is enforced and MD5 is disabled, and how entitlement filters are enforced in queries. |
| Operational skills and monitoring | A pgvector build adds index maintenance, memory tuning for HNSW builds and vector-specific query monitoring to a database team that already runs PostgreSQL. A dedicated store adds a second database platform with its own upgrades, backups and on-call. | Whether your database team has capacity for vector index tuning, and whether your monitoring already covers index size, build time and query latency for the vector tables. |
| Scale at which teams split out | A single PostgreSQL instance is simpler until vector count, index size, filter complexity or query rate outgrows what the instance can serve with acceptable recall and latency. Splitting out usually means moving vectors and their sync logic to a dedicated store. | Expected vector count and growth, target query rate, acceptable recall and latency, and a load test that shows where your current database stops meeting those targets. |
Which platforms fit a PostgreSQL-first estate and why
A PostgreSQL-first estate can often start vector search with the database it already runs, but the choice depends on how much filtering, scale and per-collection access control the workload needs. The three options below differ mainly in where vectors live, who operates them, and which security settings must be in place before any data is loaded.
pgvector on existing PostgreSQL
Adds vector columns and indexes to a PostgreSQL database your team already backs up, monitors and patches, so vectors sit next to the relational data they describe. It suits one database standard, moderate vector counts and queries that join embeddings with business tables. Check that your PostgreSQL major version is still supported, since pgvector supports PostgreSQL 13 and later, and confirm that filtered queries return enough results under your index settings.
pgvector on dedicated instances
Runs a separate PostgreSQL cluster for vector workloads so embedding indexes do not compete for memory, CPU or maintenance windows with transactional systems. The trade-off is a second database to back up, patch, replicate and restore on the same schedule as your other data stores. Agree which team owns it, how restores are tested, and how a failover is handled, because PostgreSQL does not detect a failed primary by itself.
Self-hosted Qdrant
A dedicated vector engine licensed under Apache-2.0 that fits when filtering, scale or per-collection permissions outgrow pgvector. It needs block storage with a POSIX-compatible file system, so NFS and object storage are not options, and SSD or NVMe drives are recommended. Qdrant instances listen on all interfaces with no authentication by default, so API keys, TLS and network restrictions must be configured before any document-derived data is loaded.
Qdrant access control and audit
Qdrant offers admin and read-only API keys, TLS for REST and gRPC, JWT-based access with per-collection read or write permissions, and JSON audit logging of authenticated API operations. These controls are the ones an access review will ask about for embedded documents. Confirm that the version you deploy includes each feature you rely on, and decide how audit logs are retained and who reviews them.
Qdrant distributed mode
Splits collections into shards across nodes with a replication factor for extra copies, coordinated through Raft consensus. Production clusters need at least three nodes so quorum survives a node failure, and the replication factor of 2 doubles storage. Teams moving here take on cluster operations, node sizing and rebalancing work that a single PostgreSQL primary does not require. Ask whether the Helm chart or the enterprise operator fits your Kubernetes operating model, since the community chart lacks zero-downtime upgrades and automatic shard rebalancing.
How pgvector and a split-out store connect to the application
The simplest pattern installs the pgvector extension in the database that already holds the source records, so the application writes a row and its embedding in one transaction. The trust boundary does not move: the vectors inherit the same roles, row-level policies, TLS settings and backup jobs as the relational data. The main cost is contention, because embedding writes and vector index maintenance share CPU, memory and I/O with transactional traffic.
- Single transaction writes: Source rows and embeddings commit together, which removes a class of drift between systems.
- Read traffic on replicas: Hot standbys serve read-only queries, so similarity searches can run against a replica while writes stay on the primary.
- PgBouncer in front: A connection pooler such as PgBouncer limits the number of backends that vector queries open against the primary.
- Pipeline writes on the primary: The embedding job should write through a dedicated role with insert and update rights only on the vector column and its table.
- Replica lag: Asynchronous replicas can return results that miss the newest embeddings, so confirm how fresh retrieval must be.
Check whether the primary has headroom for index builds and whether your replica lag tolerance matches the retrieval use case.
A dedicated cluster keeps vector workloads on their own PostgreSQL instances, so index builds and similarity queries cannot starve the transactional database. The same engine, extension and operational runbooks apply, which keeps the team's skills useful. The trust boundary becomes a separate database with its own authentication configuration, network path and access list, which is easier to scope in an audit but adds a second system to patch, back up and monitor.
- Isolated resources: Memory and storage sized for the vector index do not compete with OLTP workloads.
- Authentication settings: Client authentication methods such as SCRAM, certificates or OAuth can be set per cluster, so the vector cluster can follow its own policy.
- Independent upgrades: Major version upgrades can be scheduled for the vector cluster without changing the primary.
- Duplicate operations: Backups, point-in-time recovery and failover tooling must be configured twice.
- Data movement: Source records still need a sync path into the dedicated cluster, so confirm who owns that job and how it recovers from failure.
Confirm that the operations team can run two clusters with the same backup and restore discipline.
This pattern keeps source records and their authoritative state in PostgreSQL and places the embeddings in Qdrant, linked by a stable identifier stored in both systems. Qdrant offers a dedicated vector engine with its own API keys, role-based access through JWT and JSON audit logging, but none of these are enabled by default, so they must be configured before any data enters the cluster. The application writes to PostgreSQL first, then the pipeline upserts the vectors into Qdrant under the same ID.
- Synchronized IDs: Each Qdrant point carries the primary key of its source row, so deletions and re-embedding can be traced in both directions.
- Secure defaults: Self-deployed Qdrant listens on all interfaces without authentication, so bind addresses, TLS and API keys are the first configuration tasks.
- Storage requirements: Qdrant needs block storage with a POSIX-compatible file system, not NFS or object storage, and SSD or NVMe is recommended.
- Production topology: Distributed mode uses Raft and recommends at least three nodes so quorum survives a node failure.
- Replication scope: Qdrant's replication factor duplicates vector data for availability, which doubles storage at a factor of 2, but does not replace PostgreSQL backups.
Confirm who owns the sync job, how it handles failed writes, and how a deletion in PostgreSQL reaches the vector store.
Rollout from a pilot in the existing database to a split-out decision
This sequence takes vector search from a contained pilot inside the PostgreSQL estate you already run to a documented decision on whether it stays there or moves to a dedicated store. Each phase closes with an output the platform owner, security lead and application team can review.
Confirm the PostgreSQL major version and support end date
The platform team checks which PostgreSQL major version the estate runs and when its support ends, using the PostgreSQL versioning policy. Supported versions listed in the policy include 14 through 18, and the team records the end-of-support date for each cluster that will hold vectors. Output: a signed-off version record with the planned upgrade window, so the pilot is not built on a version that will leave support during the decision period. Confirm the pgvector version your distribution packages, since the extension must support your PostgreSQL release, and note that the pgvector README states support for PostgreSQL 13 and later.
Load representative data and enable pgvector
The data engineering and DBA teams install the pgvector extension on a non-production copy of the target database and load a representative sample of embeddings with their source identifiers, metadata and access attributes. They confirm the embedding dimensions against the limits in the pgvector README, including the 2,000-dimension ceiling for indexed vector columns. Output: a loaded test table with row counts, dimension checks and a documented mapping from each vector back to its source record.
Benchmark index types and filtered queries
The application and performance teams compare exact search with HNSW and IVFFlat indexes on the representative data, using the filters the product will really apply, such as tenant, document owner, classification or date range. They measure recall against exact results and latency at the query concurrency they expect, and they test filtered queries specifically, because the pgvector README notes that approximate indexes apply filters after the index scan. Output: a benchmark report that shows which index type and iterative scan setting meet the recall and latency targets the business has agreed.
Set backup, point-in-time recovery and high availability behaviour
The DBA and platform teams confirm that the existing backup tooling covers the vector tables, including continuous archiving and point-in-time recovery as described in the PostgreSQL documentation. They document the replication mode, whether a commit waits for standbys, and the failover tooling in place, since PostgreSQL does not detect a primary failure on its own. Output: a written backup, recovery and failover design that states who owns each component, how long recovery is expected to take and how a failed-over primary is handled by applications.
Define the migration trigger to a dedicated store
The architecture board writes the conditions that would move vector search to a dedicated engine such as Qdrant, with thresholds for vector count, query rate, filter complexity, index rebuild time and recovery objectives. Each trigger is tied to a measurement from the benchmark and operations phases, so the decision rests on evidence. Output: a one-page decision record that names the owner of the trigger, the metrics that will be watched and the review date. Confirm with the vendor and your own team which thresholds apply, because no fixed scale figure is set here.
Rehearse a restore before go-live
The operations team restores the vector tables from backup into an isolated environment and runs the same retrieval queries used in the benchmark against the restored data. They check row counts, index validity, query results and the link from each vector to its source record, then time the restore against the recovery design. Output: a restore test record signed by the DBA and application owner. Go-live does not proceed until a restore has succeeded, and any gap found is closed or accepted in writing.
Go live and review the split-out trigger on schedule
The team releases the pilot to production users with monitoring on query latency, index health, replication lag and storage growth, and the metrics named in the migration trigger. The architecture board reviews those metrics at the agreed interval and records whether the estate stays on pgvector or starts a move to a dedicated store. Output: a go-live approval, a monitoring dashboard the operations team owns and a dated decision log that documents each review outcome.
What teams ask before adding vector search to PostgreSQL
Is pgvector enough for our vector search workload?
For many teams already running PostgreSQL, pgvector is enough for a first production workload, and it keeps vectors next to the relational data they describe. pgvector stores vector and halfvec values up to 16,000 dimensions, supports exact search by default, and offers HNSW and IVFFlat approximate indexes on vector columns of up to 2,000 dimensions. The questions that decide the fit are your vector count, your dimension size (for example, whether your embedding model produces vectors above 2,000 dimensions), your filter patterns and your query rate. Test those against your own data before committing, because the answer depends on them more than on any general rule.
How does filtering affect pgvector query results?
Filtering is the detail most teams underestimate. The pgvector README notes that with approximate indexes, filters are applied after the index is scanned, so a selective filter can return fewer results than expected. pgvector offers iterative index scans in strict or relaxed ordering modes to fetch more candidates when filters remove too many rows. For entitlement-aware retrieval, where users may only see documents they are allowed to read, validate these settings with realistic permission patterns and check recall for each important filter combination.
What drives the effort and cost of staying on PostgreSQL versus splitting out?
Staying on PostgreSQL adds little new infrastructure, because you reuse the existing backup, high availability, monitoring, patching and access control. The cost grows as vector tables compete with transactional workloads for memory, CPU and I/O, and when index builds and re-embedding jobs need maintenance windows. Splitting out to a dedicated engine such as Qdrant adds a second system to back up, secure, upgrade and monitor, plus data synchronization between the two. Qdrant documents that its production clusters, including distributed mode with a replication factor, need block storage and extra copies, which doubles storage at a factor of 2. Ask any partner to price both paths against your measured vector count and query rate.
How long does a pgvector pilot take?
A pilot is shaped by the work you cannot skip: agreeing the embedding model and dimensions, loading a representative document set, building the indexes, measuring recall and latency under your filters, and testing restores. The duration depends on data volume, how many source systems feed the pipeline, and how quickly your DBAs and security reviewers can respond. DeployOpen plans pilots as fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, so the timeline in your quote will reflect the agreed measurements rather than a generic estimate.
What does the work need from our DBAs and security team?
Your DBAs own the database lifecycle, and the work touches several of their tasks. They will review extension installation, index build memory settings, replication and failover design, and the upgrade path. PostgreSQL 18 is the newest supported major version, and PostgreSQL 14 is supported only until November 12, 2026, so the upgrade calendar matters. Security teams should review client authentication (PostgreSQL supports SCRAM, certificate, LDAP and OAuth methods), TLS, role design for read and write access, and audit logging. Agree these responsibilities early, because the evidence you produce for auditors comes from these same controls.
What happens to our high availability and backups when vectors live in PostgreSQL?
Vectors inherit the database's existing protections, which is one of the main reasons teams choose pgvector. PostgreSQL supports hot standby replicas, synchronous and asynchronous replication and point-in-time recovery through continuous archiving. It does not include automatic failover, so you need an external tool to detect a primary failure and promote a standby. Confirm that your restore procedure covers the vector tables and that an index rebuild after restore fits your recovery time expectations. Test restores with the same process your auditors will see.
Can our own team run this without outside help?
Many teams with experienced PostgreSQL operators can run pgvector internally, especially for a modest, well-understood workload. The gaps usually appear in embedding pipeline design, retrieval evaluation, filter tuning, security hardening of the vector path and documentation for compliance evidence. A partner is most useful for independent testing, a written readiness review and handover of runbooks. Whether your team can do it alone depends on the skills you have in-house and the number of people available to operate it after go-live, which you should assess honestly before deciding.
Evidence auditors ask for from a PostgreSQL vector store
This table maps the evidence an assessor typically samples for a pgvector deployment to the PostgreSQL component that produces it. Read each row as a question to answer with a record from your environment. DeployOpen prepares evidence and controls for compliance assessments, but auditors and certification bodies issue the assessment outcome.
| Evidence item | What it shows | Where it comes from | What to confirm before an assessment |
|---|---|---|---|
| Access configuration | Who can connect to the vector database and by which method | PostgreSQL client authentication methods in pg_hba.conf, including certificate, LDAP, GSSAPI or OAuth where your identity provider supports them | Confirm that MD5 password authentication is not used and that the vector schema has no broad default grants |
| Encryption in transit | Client and replication connections use TLS with approved protocol settings | PostgreSQL SSL settings, server certificates and replication connection configuration | Confirm certificate expiry dates, cipher settings and that pooler connections such as PgBouncer are also encrypted |
| Encryption at rest | Storage volumes holding vector and table data are encrypted | Storage platform configuration in your cloud account or data center, not PostgreSQL itself | Confirm the encryption method, key custody and whether backups and WAL archives are covered |
| Backup and PITR records | Base backups and archived WAL exist and a point-in-time restore has been tested | Continuous archiving configuration, backup tool logs and restore test reports | Confirm retention periods, restore test dates and that vector columns were checked after restore |
| Replication and failover runbook | How a standby is promoted and how applications reconnect after a primary failure | Hot standby and replication configuration, plus the external failover tool you use, since PostgreSQL does not detect failure on its own | Confirm the failover tool, test records and who can authorize promotion |
| PostgreSQL version support status | The running major version is still within its supported window | PostgreSQL versioning policy dates and the output of the server version query | Plan any move off a version approaching end of support, such as 14, before its published end date |
| pgvector version and change records | The extension version in use and when it changed | pgvector release notes and the extension version recorded in the database | Confirm the pgvector version is compatible with the PostgreSQL major version and that index rebuilds are logged |
| Upgrade change records | Each minor or major upgrade was planned, tested and approved | Change tickets, pg_upgrade or logical replication run logs, and pre and post upgrade checks | Confirm rollback steps and that planner statistics and vector index behavior were checked after the upgrade |
| Audit logging of database activity | Who accessed or changed vector data and when | PostgreSQL logging configuration and any audit extension or log shipping you have approved | Confirm which statements are logged, where logs are stored and how long they are retained |
When teams split out to a dedicated vector database
Teams should split vector search out of PostgreSQL when one of four triggers appears in measurement, not when a benchmark looks unfavorable. The first is filtered approximate search returning too few results. pgvector applies filters after an approximate index is scanned, so a selective filter such as a tenant, a department or an access group can leave fewer matches than the query needs. Iterative index scans in strict or relaxed ordering modes help, but they add query cost, and the team should measure recall under the filters real users apply. The second is dimension or index needs beyond pgvector limits. The vector type covers up to 16,000 dimensions, but HNSW and IVFFlat indexes apply to vector columns of up to 2,000 dimensions, so models with larger outputs need halfvec indexing or a different store. Confirm the embedding model's output size and the index type your recall target requires before committing.
The third trigger is vector workloads competing with transactional load. Index builds, large batch re-embeddings and high query rates consume the same CPU, memory and I/O as order processing or ledger writes, and the database team may find that replicas serving reads are the wrong place to absorb that load. The fourth is separate lifecycle or tenant isolation needs, such as a different upgrade cadence for the vector store, distinct backup retention, or per-tenant deletion that the relational estate cannot isolate cleanly. Measure p95 and p99 query latency with production filters, index build and rebuild time, memory footprint of the index against available RAM, and transaction latency on the shared primary while vector jobs run. Note that PostgreSQL major upgrades can use logical replication, but moving vectors to another store means exporting the vectors and payloads and rebuilding indexes in the target, so plan for re-indexing and a parallel-run period for recall comparison. Ask any partner to show these measurements before recommending a split.
How to move vectors later without losing the audit trail
The sequence keeps every vector traceable to its source record while moving search from pgvector to a dedicated store, so reads switch over only after counts and query results match. Each step ends with a check you can record as evidence for auditors.
Inventory embeddings and their source linkage
Before any data moves, the team lists every table holding vectors, the embedding model and version that produced each one, the dimension count, the distance operator used in queries, and the key that links each vector to its source record, chunk and access rules. This inventory is owned by the data team with input from the security team, because the linkage is what proves later where a vector came from. It is done when every collection has a written record and someone outside the build team has reviewed it.
Decide between export and re-embedding
The team chooses whether to copy existing vectors or regenerate them. Copying keeps the original embeddings and is faster to reproduce, but only if the target store accepts the same dimensions and type. Re-embedding is needed when the embedding model changes or when the target store requires a different format, and it creates a new set of vectors that must be logged against the new model version. The decision and its reason are recorded in the change ticket so the audit trail explains why the vectors differ.
Load the target store with stable identifiers
Vectors and their payloads are written to the dedicated store using the same identifiers that link them to source records, so no lookup table is invented during the move. The load runs against a non-production copy first and is repeated on the production data after the test passes. The output is a load log showing batch counts, failed records and the version of the target software, which the team keeps with the migration record. Confirm the target's supported vector types and dimension limits against its own documentation before loading.
Validate counts and sample queries
The team compares record counts per collection, checks that the source identifiers match, and runs a fixed set of sample queries against both stores. Results are compared by identifier and rank, and any difference is investigated and explained in writing. Filtered queries are included in the set because filter behaviour can differ between pgvector and a dedicated engine. The validation report, with the query set and results, is the main evidence that the move did not change what users retrieve.
Cut over reads in a controlled window
Application configuration is changed so that reads go to the new store, with the previous path kept available for a rollback period agreed in advance. Writes are paused or dual-written for the window so that no new vectors are missed, and the team confirms which source feeds each collection. Access controls, TLS settings and API keys on the new store are verified before traffic moves. The cut over is complete when the configuration change, the time of the switch and the first monitored queries are logged.
Keep source-record linkage and deletion paths working
After the cut over, the team tests the processes that depend on the link between vectors and source records: deleting a vector when a source document is removed, honoring an erasure request, and restoring a single document. Snapshots and backups of the new store are included in these tests because they can still hold deleted content. The output is a test record showing each deletion path was exercised on the new store, which matters for any assessment that samples data lifecycle controls.
Retire the old index with a recorded decision
Once the rollback period closes without a reason to return, the old pgvector indexes and columns are dropped, and any backups that hold them are handled under the retention rules already agreed. The drop is done as a separate change with its own approval, and the database administrator records the statement and the time it ran. The final record ties the old and new stores together, so an auditor can follow a result back from a query log to the source record and the store that served it.
How DeployOpen scopes and supports a PostgreSQL vector search build
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that includes pgvector on an existing PostgreSQL estate. We start from the database you already operate, agree the vector workload in writing, and hand over a system your own team can run.
How we scope
- Inventory the PostgreSQL versions, replication setup and backup tooling already in use before any extension is added
- Record vector count, embedding dimensions, filter combinations and recall expectations in the written scope
- Agree fixed deliverables, timelines and exclusions in writing before work starts, with a quote following from that scope
How we build
- Install pgvector on a tested PostgreSQL version and compare exact search with HNSW or IVFFlat indexes on representative data
- Configure filtered queries and iterative index scans so tenant or permission filters do not silently drop results
- Set connection pooling, authentication methods, TLS and role separation for the vector schema and application users
How we hand over
- Document the index build settings, re-embedding procedure and the point at which the workload should move to a dedicated engine
- Run and record a restore test from backups that include the vector columns, with the extension version noted
- Train the operations team on upgrades, extension version checks and monitoring of index size and query latency
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan PostgreSQL minor and major upgrades and pgvector version changes as scheduled, tested work
- Confirm with the client's security team which evidence they need, such as access reviews and backup logs, and collect it on a set cadence
