Somewhere in your client's AWS bill there is a line item from 2023: a dedicated vector database, provisioned in a sprint of pure optimism, during the brief window when every architecture diagram needed a new box labeled 'Vector DB' or the whole project looked behind the times.
It is 2026 now. That box is quietly being deleted. Not because the idea was wrong, but because somebody on the platform team finally asked the question everyone was too excited to ask in 2023: do we actually need a whole new system for this, or do we just need an extension?
If you are a consultant bouncing between clients, you have probably lived both halves of this pendulum swing in the same calendar year. One client wants you to stand up Pinecone. The next wants you to rip it out and move everything into pgvector on the RDS instance they were already paying for. Both requests can be reasonable. Here is how to tell which is which, and how to sound credible saying so in a client meeting instead of just repeating a hot take from a conference talk.
How we got here: the 2023 vector database gold rush
When retrieval-augmented generation went mainstream, the fastest path to a demo was a purpose-built vector store. Pinecone, Weaviate, Qdrant, and Milvus all had managed offerings, simple SDKs, and marketing that made 'add embeddings' sound like it required entirely new infrastructure. For a proof of concept under deadline pressure, that was often true. Nobody had time to tune an index inside their existing database while also figuring out chunking strategy and prompt templates.
So teams bought the new thing. Some of those systems genuinely needed it. A lot of them were storing a few hundred thousand document chunks and could have fit comfortably in a side table.
What changed: pgvector grew up
pgvector has been around since 2021, but the releases since then matured it considerably. HNSW indexing landed in pgvector 0.5, giving it an approximate nearest neighbor option that is competitive with what dedicated stores use under the hood, alongside the earlier IVFFlat index. Postgres already does the things platform teams were tired of re-solving in a second system: backups, replication, access control, observability, and a SQL interface your whole team already knows.
The pitch for 'just use Postgres' in 2026 is not that pgvector is faster than a dedicated vector store. It usually is not, at real scale. The pitch is that for a large share of real workloads, the dedicated store was never the bottleneck, and running one more distributed system was pure operational tax.
pgvector vs a dedicated vector store: the honest scorecard
This is the comparison worth having with a client before you move anything, in either direction.
| Dimension | pgvector on Postgres | Dedicated vector store |
|---|---|---|
| Operational overhead | One system to run, patch, and monitor | Separate cluster, its own on-call burden |
| Scale ceiling | Comfortable into tens of millions of vectors with tuning; gets harder past that | Built for hundreds of millions to billions, with horizontal sharding |
| Metadata filtering | Native SQL joins and WHERE clauses, very flexible | Supported, but often bolted on and less expressive |
| Hybrid search (keyword plus semantic) | Combine with Postgres full-text search in one query | Usually requires a second system or a newer hybrid feature |
| Multi-tenancy at scale | Works, but index maintenance per tenant can get heavy | Designed for it from the ground up |
| Latency under heavy concurrent load | Good, degrades as index size and write volume grow | Generally more consistent at high query-per-second |
| Team already knows it | Very likely yes | Usually no, new tool to learn |
When a dedicated vector store still earns its place
Be honest here, because overselling pgvector in a client conversation will embarrass you in six months. A dedicated vector store still makes sense when:
- You are genuinely operating at hundreds of millions of vectors with high query volume, not a few million that feels big because the demo was slow once.
- You need real-time index updates at high write throughput without rebuilding or waiting on index maintenance windows.
- You need multi-tenant isolation with per-tenant indexes at a scale where Postgres table bloat becomes its own project.
- Your product is the retrieval system itself, and search latency under load is a customer-facing SLA, not an internal convenience.
- You need advanced hybrid search, reranking, or filtering features that are still ahead of what pgvector ships out of the box.
None of that is nostalgia for 2023. It is a real workload profile, and it shows up more often at companies with actual production AI traffic than at companies still running a single RAG pilot.
What to say when a client asks you to rip one out
This is the conversation you will have more than once this year, and it is worth having a script. Do not lead with vibes. Lead with numbers you can actually pull.
- Ask for current vector count, write frequency, and p95 query latency from the existing dedicated store. If nobody has these numbers, that itself is informative.
- Run a side-by-side benchmark with pgvector using HNSW on a copy of the real data, not a synthetic sample. Ten minutes of honest benchmarking beats an hour of opinions.
- Check whether the app already needs hybrid search or heavy metadata filtering. If yes, pgvector's SQL-native approach might simplify the query layer, not just the ops layer.
- Price out the migration itself. Moving embeddings and rebuilding indexes is not free, and a consolidation project needs to pay for itself in reduced ops cost or it is just change for its own sake.
- Be willing to say 'keep it' out loud. If the numbers support the dedicated store, your job is to say so even if the client came in hoping for a tidy consolidation story.
The useful version of this skill is not knowing that Postgres added vector support. Everyone saw that announcement. The useful version is being the consultant in the room who can look at actual query patterns and tell a client which side of the pendulum they are really on, instead of which side is trending on social media this quarter.
The takeaway worth remembering
The architecture pendulum did not prove vector databases were a mistake, and it did not prove Postgres can do everything. It proved that most teams adopted new infrastructure before they measured whether they needed it. That is a pattern bigger than vector search, and consultants who can spot it early are the ones clients call back.
If you want to talk through how this kind of architecture-pendulum judgment plays into your next contract, or you are weighing which data and platform skills are worth sharpening this year, the team at Josh Pros LLC is happy to talk shop. Email contact@joshpros.com or visit https://joshpros.com.
#pgvector #VectorDatabase #PostgreSQL #DataEngineering #RAG #AIInfrastructure #TechConsulting #CloudArchitecture #ContractConsultants #PlatformEngineering #MachineLearningOps #JoshProsLLC
Talk to a real recruiter, not a bot.
We'll tell you the rate, the client, and the terms before you interview. And if we're not the right fit, we'll say so.