Vector Database: pgvector vs Qdrant vs Managed Service

Vector Database: pgvector vs Qdrant vs Managed Service

If you already run Postgres, the most sensible path is usually to start with pgvector. You reuse the backups, access controls, monitoring and team you already have. Qdrant starts to make sense when vector search becomes a workload of its own, with high volume, complex filters or a need to isolate performance. A managed service is worth it when the company does not want to operate anything and accepts depending on a vendor.

Key takeaways

• If you already have Postgres and a small to mid-sized document set, pgvector is the starting point with the lowest operating cost.
• Qdrant pays off when vector search puts load on your main database, when filters are sophisticated, or when you want to scale search separately from transactions.
• A managed service trades operational work for vendor dependence and a bill that grows with usage.
• Permission filtering is the requirement that most shapes the architecture: anyone who is not allowed to see a document should never have it reach the model's context.
• The real cost is upkeep: upgrades, reindexing, backups, monitoring and who answers the alert in the middle of the night.

What a vector database solves and what it does not

A vector database stores numeric representations of text (embeddings) and lets you find what is semantically close to a question. It is the retrieval piece of a RAG architecture, where the system fetches relevant passages and hands them to the model so it can answer based on them. AWS describes RAG in exactly these terms, as a combination of retrieval and generation.

What it does not solve: document quality, how text is split into chunks, access rules and answer evaluation. Plenty of companies spend weeks comparing databases when the real problem is an outdated manual or a passage cut in the middle of a rule. Before choosing the technology, look at the whole design, as the Google Cloud reference architecture for RAG does: ingestion, indexing, retrieval, generation and control.

The business question comes before the technology question. What decision or customer interaction will this search support, who is allowed to see each piece of information, and what happens when the answer is wrong?

pgvector: when the Postgres you already have is enough

pgvector is a Postgres extension that adds a vector type and similarity operations. It offers approximate indexes, such as HNSW and IVFFlat, that trade a little exactness for speed. For many company use cases (internal knowledge base, customer support, proposals, contracts), that is enough.

Practical advantages if you already run Postgres:

• One system: business data, metadata and vectors in the same transaction and the same backup.
• Ordinary SQL filters: permission, customer, unit, status and date become WHERE clauses and joins your team already knows.
• Familiar security: roles, schemas and, where it fits, Postgres row level security.
• Less surface to audit, which helps in LGPD conversations and in a data protection impact assessment when the project handles personal data.

Limits to respect: vector search consumes memory and processing, and it competes with the transactional workload if both sit on the same instance. Approximate indexes combined with very restrictive filters can return fewer results than expected, depending on version and configuration. That is not a reason to rule the option out. It is a reason to test with the real filters from your case. A read replica, or a separate instance used only for search, usually solves the resource contention without changing technology.

Qdrant: when search becomes its own workload

Qdrant is an open-source vector database. You can run it on your own servers or use a hosted service from the company that maintains it. It was designed for vector search with filters over metadata (the payload), and that shows in daily use: filtering by attributes during the search is a core part of the product, not an add-on.

When Qdrant is worth considering:

• The volume of vectors grows to the point that search competes with your main Postgres.
• Filters are numerous and combined (unit, access profile, language, validity, document type).
• You need to scale and tune search independently from the rest of the system.
• More than one product or agent consumes the same retrieval layer.

The price is operational. You now have one more service to deploy, upgrade, secure, monitor and restore. Synchronization also appears: when a document changes in the source system, the vector must change in Qdrant, and someone has to make sure that happens and that deleted records really disappear. For companies with LGPD on the radar, a deletion request from a data subject has to reach both places.

Managed service: what you buy and what stays yours

A managed service can be a cloud vector database, an offering from your cloud provider (vector search inside the cloud platform you already use) or the hosted version of an open-source product. What you mainly buy is time: provisioning, upgrades, high availability and scaling stop being your team's job.

What stays yours, whichever vendor you pick:

• The rule for who can see what, and the guarantee that it is applied on every query.
• The quality and freshness of the indexed documents.
• Answer evaluation and quality monitoring.
• Compliance: the data processing agreement, storage location, subprocessors and international transfer, which Brazil's data protection authority (ANPD) oversees.

The specific risks are dependence (migrating later means reindexing and adapting queries), a bill that follows usage, and less visibility into what happens inside. For a company with nobody who wants to take care of infrastructure, it can be the right choice. Just make that decision with open eyes, and not because it looks like the simplest option in the first week.

How to handle permission filters without leaking documents

This is where RAG projects most often go wrong. If an internal assistant answers with a passage from a document the user should not see, the damage is already done. Asking the model to hide it afterwards does not help. The access rule has to be applied before the text reaches the context, and not in the prompt instructions. The OWASP authorization guidance reinforces principles that apply here: deny by default, verify on every request and apply least privilege.

A safe design usually follows these steps:

• Each indexed chunk carries access metadata (group, unit, customer or confidentiality level) inherited from the source document.
• The user's identity comes from the company's authentication system, never from something the user types in the conversation.
• The search query always includes the permission filter, built by application code and not by the model.
• Unclassified documents are excluded by default.
• Permission changes at the source update the index, within a defined time window.
• Tests include attempts at unauthorized access, and logs record which chunks were delivered to whom.

How each option helps: in pgvector, the filter can be a join against permission tables you already maintain, and row level policies give you a second barrier. In Qdrant, payload filtering is natural, but the source of truth for permissions stays outside it, so synchronization is the critical point. With a managed service, check how the filter is applied, whether there is isolation by namespace or collection, and how access is audited. Whichever you choose, input and output controls help, as we describe in guardrails for AI agents, but they do not replace the filter in the query.

Maintenance cost: what to weigh beyond the bill

The naive comparison looks at infrastructure price. The useful comparison looks at cost per unit of value delivered, the logic of FinOps unit economics: how much it costs to keep search running for each business flow it serves.

Items that tend to be left out of the first estimate:

• Reindexing when you change the embedding model (old vectors stop being comparable with new ones).
• Upgrades of versions, extensions and indexes.
• Backups, tested restores and an incident plan.
• Monitoring of latency, memory use and search quality, with the same discipline as any production system (the observability concepts from OpenTelemetry apply here).
• A named owner. A component with no owner becomes a risk, no matter where it is hosted.
• Exit cost: the effort of moving to another option in the future.

In practice, pgvector tends to have the lowest incremental cost for anyone with a Postgres team, because maintenance adds to existing routines. Self-hosted Qdrant requires a new routine. A managed service reduces the routine, but the bill then depends on usage and on the contract.

How to decide and pilot without betting everything

A simple decision guide if you already use Postgres:

• You have well-operated Postgres, a moderate document base, and permission filters tied to your database: start with pgvector.
• Search is weighing on the main database, but the team knows how to operate infrastructure: consider a dedicated Postgres instance before changing technology.
• Filters are complex, volume is growing and several systems consume the search: evaluate Qdrant, with a named owner for synchronization.
• There is no team to operate it and the company accepts dependence: evaluate a managed service, paying attention to the data contract, storage location and exit cost.
• Sensitive or strictly confidential data: prioritize the option where you control where the data lives and that is easiest to audit.

Illustrative scenario: a distributor with Postgres already in production wants an assistant that answers sales reps' questions about commercial policies and technical datasheets, with different rules per region. The documents are few and change a few times a month. Here, pgvector with a region column and a profile column on each chunk solves the filter with ordinary SQL, with no new service. If, months later, the assistant starts serving support and legal as well, with many more documents and simultaneous users, the team will already have real metrics to judge whether moving search to Qdrant or a managed service is justified.

The method we apply is the same for any of the three options. Map: documents, owners, access rules and the flow the search will support, with a measured starting point. Limit: which data goes into the index and which actions the agent may take from the answers. Pilot: one real flow, with logs of every retrieved chunk and a success metric agreed in advance (see how to measure an AI automation pilot). Hand over: document the operation, name the owner and decide whether to expand, adjust or stop. If the assistant will answer through WhatsApp, the retrieval layer is only one part, and the guide to integrating AI into WhatsApp covers the rest of the design.

A practical migration rule: always keep the original text and metadata in the source system, and treat the vector index as something that can be rebuilt. That way, moving from pgvector to Qdrant or to a managed service becomes a planned reindexing, not a data loss.

Frequently asked questions

Can I start with pgvector and migrate later? Yes, and it is a common strategy. If the original text and metadata stay in the source system and the index can be rebuilt, migration is a reindexing plus an adaptation of queries. What needs care is keeping permission logic in one application layer, and not scattered across queries that are hard to port.

Is Qdrant faster than pgvector? It depends on volume, filters, configuration and hardware, so there is no reliable general answer. On smaller datasets, the difference often does not show up for the end user. Test with your documents, your filters and your expected traffic, and measure latency and result quality, not just speed.

Does a managed service solve LGPD compliance? Not by itself. The vendor takes care of part of the infrastructure, but the company remains responsible for purpose, legal basis, access control and handling data subject requests. Check the processing agreement, storage location and subprocessors, and follow what companies should watch in Brazil's AI regulation.

Is the vector database what most influences answer quality? Rarely. Quality comes more from good document splitting, up-to-date content, a good embedding model, correct filters and ongoing evaluation with real questions. Switching databases without fixing those points usually changes the result very little.

Sources

• AWS: What is retrieval-augmented generation
• Google Cloud: retrieval-augmented generation architecture
• OWASP: authorization guidance
• FinOps Foundation: unit economics