Best fit: keep pgvector in PostgreSQL if PostgreSQL already supports your RAG application and vector search has not caused reproducible resource contention. Review the pgvector 0.8.7 fixes and plan any required extension update; do not treat the release as a reason to migrate data. Consider Qdrant when measurements show a need for independent scaling, isolation, or retrieval-specific tuning.
This is for developers and small teams already using PostgreSQL and pgvector for a self-hosted knowledge base.
It is also for technical leads deciding whether a separate vector service solves a measured operational problem—or just adds another component to run.
Last updated October 24, 2026. Release details checked against the pgvector change record and the PostgreSQL announcement for pgvector 0.8.7. Qdrant security boundaries checked against its official security documentation.
The release update and the architecture decision
The pgvector change record dates version 0.8.7 to October 1, 2026; the PostgreSQL announcement followed on October 5, 2026. The announcement describes security fixes. Those dates and notices make the release worth reviewing, but they do not establish that every deployment was vulnerable or exposed. Use the official announcement and change record to check the stated fix scope against your installed version and how you use the extension. Do not infer exposure from the version number alone.
Keep two decisions separate:
- Update decision: Does your deployment need the fixes, and can you apply the extension update safely?
- Architecture decision: Does PostgreSQL still meet your consistency, retrieval, resource, and operational requirements?
An extension update does not, by itself, change where your vectors need to live. pgvector stores vector data in PostgreSQL, so a team already operating that database may be able to keep application records and embeddings under its existing database processes. Qdrant is a separate service: it can give you an independent place to operate vector search, but also creates additional network, security, monitoring, and recovery responsibilities.
Community threads can help you discover the questions other self-hosting teams ask, but they do not prove which option performs better for your workload. Treat the vector-database comparison discussion as an example of user discussion, not as a representative benchmark or a substitute for testing your own queries.
The decision by operational metric
Use your current PostgreSQL environment as the baseline. A separate database is justified by a concrete requirement, not by the fact that a standalone product exists.
| Decision metric | Keep pgvector in PostgreSQL when… | Evaluate Qdrant separately when… |
|---|---|---|
| Data consistency | Application records and vectors benefit from the same PostgreSQL transactions and maintenance practices. | Your design can tolerate and correctly manage data flow between separate services. |
| Resource isolation | Monitoring does not show recurring conflict between vector search and application SQL. | You can reproduce contention and need vector workload maintenance or scaling to be independent. |
| Query fit | Tests with your actual dimensions, filters, updates, and retrieval patterns meet your requirements. | Your evaluated retrieval needs are not met by the PostgreSQL setup you have tested. |
| Operations | Your team can maintain one database service with its current access and recovery procedures. | Your team can take responsibility for securing and operating another network-accessible service. |
These are conditional choices, not a universal ranking. A team with established PostgreSQL operations may find the shared service simpler; a team that needs separate resource controls may value an independent service enough to accept its additional operational work.
| Observed signal | What to inspect before changing architecture | Next action |
|---|---|---|
| Application queries slow down during retrieval activity | Query timing, database activity, and whether the affected SQL overlaps with vector searches | Identify and reproduce the competing workload before proposing separation. |
| Index builds or maintenance interfere with application work | Maintenance timing, resource pressure, and the impact on normal database queries | Test a different maintenance window or query plan before introducing another service. |
| Vector queries miss retrieval requirements | Actual filters, update patterns, dimensions, and retrieval quality on representative data | Run a controlled comparison using the same inputs and evaluation method. |
| The database team cannot isolate the required workload | Current deployment controls and the level of independent scaling or maintenance required | Estimate the full operating cost of a separate service, not just its deployment. |
The PostgreSQL monitoring guide describes the database monitoring facilities you can use to inspect activity. For a specific query, review its execution plan with PostgreSQL’s EXPLAIN documentation. A slow query plan is evidence to investigate; it is not, by itself, proof that a separate vector database will fix the issue.
| Test element | Hold constant in both tests | Record for the decision |
|---|---|---|
| Input data | The same documents, vector dimensions, metadata, and update state | Data-loading and update assumptions |
| Query set | The same representative questions and filters | Retrieved results and retrieval-quality assessment |
| Execution conditions | Equivalent workload, concurrency, and system conditions | Query latency and resource observations |
| Operations | The same backup and recovery expectations | Setup effort, security tasks, and recovery procedure |
Do not transplant another team’s performance result into your capacity plan. An apples-to-apples test means using the same dataset and query set, evaluating retrieval quality in the same way, and recording resource use and query latency under conditions that resemble your own service. If you cannot reproduce a problem or define what an acceptable result looks like, you do not yet have evidence that splitting the database is the right remedy.
Retrieval fit and resource contention
A vector store decision is not just a choice between two product names. Your query shape matters. List the vector dimensions, metadata filters, update frequency, and any combined text-and-vector retrieval your application actually uses. Then check those needs against the pgvector project documentation and the Qdrant documentation for the deployment you plan to run. Verify the behavior you depend on; do not assume similarly named options have identical semantics.
For a PostgreSQL RAG system, also consider how vector work interacts with ordinary application SQL. Inspect query timing and execution plans for representative retrieval and application queries. Check whether index building, refreshes, or bursts of document updates coincide with degraded application behavior. The relevant question is not “Is vector search using resources?”—it necessarily uses resources—but “Can you demonstrate that this work is interfering with another requirement, and would separation address that interference?”
A practical comparison can use one replayable query set:
- Select representative knowledge-base queries and filters from application logs, removing sensitive content where needed.
- Use the same document snapshot and embedding data in each test environment.
- Define how your team will judge retrieval quality before running the comparison.
- Run the same query sequence under comparable load and record latency, resource observations, and failures.
- Repeat the test after changing only the database design or tuning under evaluation.
This does not produce a universal winner. It tells you which option fits the workload and operating constraints you actually have.
Upgrade and deployment risk
Before you update pgvector, establish the installed extension version and PostgreSQL environment. Confirm that the extension package or managed installation path provides the target version, review the project’s documented upgrade instructions, and schedule the change using your own database maintenance process. The project documentation, not a generic command copied from an unrelated installation, should determine the exact steps for your environment.
You can start by checking the installed extension version:
psql "$DATABASE_URL" -c \
"SELECT extversion FROM pg_extension WHERE extname = 'vector';"
A sample result might be:
extversion
------------
0.8.7
Treat that as an example of output, not proof that an installation is current or that an update is required. Compare the result with the official pgvector change record, then follow the project’s documented upgrade procedure for your installation. Check whether your PostgreSQL environment needs an extension package update before applying a database-level extension update.
A separate Qdrant deployment adds its own security boundary. Review the official Qdrant security documentation before exposing the service: configure appropriate access controls and network restrictions instead of assuming a fresh deployment is ready for public access. Also decide how you will monitor it, restore it, and validate recovery. Qdrant documents its snapshot mechanisms in its snapshot operations guide; a snapshot feature is not the same as a complete backup and recovery plan. Define where recovery data will reside and test that your process can restore the service.
The split architecture can also make consistency an application responsibility. If a document update writes to PostgreSQL and separately updates a vector service, plan how you handle a partial failure, retry, or stale vector record. Do not assume that two services share a transaction simply because the application updates both.
A verification checklist
Use this sequence before changing production architecture. If you cannot complete the checks, collect the missing evidence first.
- [ ] Record the PostgreSQL version, installed pgvector version, installation method, and extension update path.
- [ ] Read the 0.8.7 change record and release announcement; determine whether the stated fixes apply to your version and usage.
- [ ] Confirm that you can restore the database using your existing recovery procedure before applying an update.
- [ ] Run representative application SQL and vector queries through the PostgreSQL monitoring and query-plan checks.
- [ ] Record any reproducible contention, including what workload triggers it and which application requirement it affects.
- [ ] Test retrieval quality and resource use on the same data and query set before comparing pgvector with Qdrant.
- [ ] If evaluating Qdrant, document its authentication, network exposure, monitoring, backup, and restore responsibilities.
- [ ] Choose to keep one database or split the service based on measured needs and the team’s ability to operate the result.
For your team, a successful update and a successful architecture test are separate outcomes. Keep the update focused on the documented fixes. Keep the migration proposal focused on a demonstrated retrieval, isolation, or operations requirement.
Common questions
What are the trade-offs between pgvector and Qdrant for RAG?
pgvector keeps relational records and vectors within PostgreSQL, which can simplify transactions, access control, and routine database operations when your team already runs PostgreSQL. Qdrant adds a separate vector service that you can manage and tune independently, but it also adds network, security, monitoring, and recovery work. Compare both against your real filters, update patterns, and queries rather than a benchmark from another environment.
If PostgreSQL already stores my application data, do you need another vector database?
Not by default. Keep vectors in PostgreSQL while the combined workload meets your retrieval and application requirements and your team can operate it safely. Consider a separate service when measurements show recurring contention, you need independent scaling or maintenance, or your retrieval requirements fit the separate system better. Adding a database without a demonstrated need creates another service to secure and recover.
Does pgvector 0.8.7 require a data migration?
The release itself does not mean you must move vector data to Qdrant. First check the official change record and PostgreSQL announcement for the fixes, determine whether your installed versions and usage are in scope, and plan the extension update using the instructions for your PostgreSQL environment. Treat the software update and the database architecture decision as separate changes.
When should you move vector search out of PostgreSQL?
Consider separation when you can reproduce resource contention between vector queries and application SQL, need to scale or schedule vector maintenance independently, or have retrieval requirements that your tested PostgreSQL setup does not meet. Before migrating, compare results on the same data and query set, and estimate the additional work for credentials, network controls, monitoring, backups, and recovery.
Choosing the server boundary
If the database and RAG application currently share a small virtual server, resource contention, limited control over the environment, and inflexible storage choices may make sustained workloads harder to plan. An independent AMD bare-metal server can be a better fit when you need dedicated machine resources for a persistent database and application stack; it does not remove the need to design access controls, backups, or recovery, and it does not guarantee a particular query speed.
If you are planning that deployment, review the available memory and disk options against the database, index, and document-store needs you measured. Confirm how you will administer the system through Linux shell access, and verify the service boundaries before you assume a feature is included. You can check OSFP Cloud’s current server information at OSFP Cloud; use the current product details to confirm available resources before committing.
For short-lived tests or a light workload that fits comfortably in your existing PostgreSQL service, adding a dedicated server may be unnecessary. First verify the pgvector update path, collect workload evidence, and decide whether the extra isolation is worth operating a separate machine or database service.
Questions
What are the trade-offs between pgvector and Qdrant for a RAG system?
pgvector keeps relational records and vectors within PostgreSQL, which can simplify transactions, access control, and routine database operations when your team already runs PostgreSQL. Qdrant adds a separate vector service that you can manage and tune independently, but it also adds network, security, monitoring, and recovery work. Compare both against your real filters, update patterns, and queries rather than a benchmark from another environment.
If PostgreSQL already stores my application data, do I need another vector database?
Not by default. Keep vectors in PostgreSQL while the combined workload meets your retrieval and application requirements and your team can operate it safely. Consider a separate service when measurements show recurring contention, you need independent scaling or maintenance, or your retrieval requirements fit the separate system better. Adding a database without a demonstrated need creates another service to secure and recover.
Does pgvector 0.8.7 require me to migrate my existing vector data?
The release itself does not mean you must move vector data to Qdrant. First check the official change record and PostgreSQL announcement for the fixes, determine whether your installed versions and usage are in scope, and plan the extension update using the instructions for your PostgreSQL environment. Treat the software update and the database architecture decision as separate changes.
When should I move vector search out of PostgreSQL?
Consider separation when you can reproduce resource contention between vector queries and application SQL, need to scale or schedule vector maintenance independently, or have retrieval requirements that your tested PostgreSQL setup does not meet. Before migrating, compare results on the same data and query set, and estimate the additional work for credentials, network controls, monitoring, backups, and recovery.
Run Your RAG Stack on Dedicated Compute
Choose OSFP Cloud for a whole EPYC 7543P server with 32 cores and 128GB or 256GB of ECC memory.
From $462 / month