Your CTO just approved a $50,000 annual contract for Pinecone.

Two weeks later, your intern added vector search to your existing PostgreSQL database in 47 minutes. For free.

This scenario is playing out in countless companies right now.

The “Golden Age” of Vector Databases

Remember back in 2023? When ChatGPT exploded and everyone said you needed a specialized vector database to store embeddings. Pinecone raised $138 million, Weaviate became a unicorn, and every startup’s pitch deck had “Powered by XXX Vector Database” on slide three.

The sales pitch was simple: traditional databases can’t handle this. You need purpose-built infrastructure. You need us.

Sounded reasonable. HNSW algorithms, approximate nearest neighbor search—those terms sound impressive.

But most companies already had a perfectly good database: PostgreSQL.

PostgreSQL Says: Actually, You Can

Developers asked a simple question: can we just add vector search to Postgres?

Vector database vendors said no, and wrote blog posts explaining why you needed specialized infrastructure.

Then pgvector came along and said actually, you can.

pgvector 0.8.0 added two game-changing features.

Iterative index scans. When you filter vectors by metadata—like “find similar products under $50”—pgvector can now scan incrementally until it finds enough results. Previously, strict filters might return empty results. Not anymore.

Smarter query planning. Postgres now knows when to use regular indexes versus vector indexes. Query for “similar products between $10-20” and it uses the price index first, then does vector search. It just works.

pgvector intelligent query planning

One Database to Rule Them All

With a dedicated vector database, your architecture looks like this:

Application → PostgreSQL (business data)
    → Pinecone/Weaviate (vector data)
    → Data sync service (keep them consistent)

With pgvector, it looks like this:

Application → PostgreSQL + pgvector (done)

No data sync. No eventual consistency bugs. No second database to monitor, backup, or scale. Just one database doing what databases do.

It’s like owning a Swiss Army knife and buying a dedicated bottle opener. Most of the time, unnecessary.

The Performance Gap Is Closing

Vector database vendors love to talk about performance benchmarks.

But they don’t tell you that pgvector 0.7.0 already supports half-precision vectors, indexing up to 4,000 dimensions, and binary quantization up to 64,000 dimensions.

Raw search speed is often not your bottleneck. The real bottlenecks are network latency between your app server and vector database, data sync lag between Postgres and your vector store, and query planning that doesn’t understand your filters.

pgvector solves all of this because the data is in the same place.

When Do You Still Need a Dedicated Vector Database?

Vector databases aren’t useless. Billions of vectors requiring distributed architecture, real-time recommendation systems where every millisecond matters, or starting from scratch without existing Postgres infrastructure—these scenarios need specialized solutions.

But most companies have millions of vectors, complex filters, and existing Postgres infrastructure. For them, pgvector isn’t a compromise—it’s the better choice.

How to Get Started?

If you’re already using Postgres, three steps:

-- 1. Install extension
CREATE EXTENSION vector;

-- 2. Add a vector column
ALTER TABLE products ADD COLUMN embedding vector(1536);

-- 3. Create index
CREATE INDEX ON products USING ivfflat (embedding vector_cosine_ops);

No new database. No data migration. No operational complexity.

Remember These Three Things

  1. pgvector 0.8.0’s iterative scans and smart query planning make Postgres native vector search truly production-ready
  2. For million-scale vectors plus complex filters, pgvector performs well and saves you the data sync headache
  3. Before signing that vector database contract, ask yourself: do I really need another database?

The vector database hype cycle is over. Not because they’re bad, but because for most use cases, they’re unnecessary.

Postgres has been running in production for 30 years. It’ll keep running.

What solution are you using for your AI applications? Dedicated vector database or already on pgvector? Share your experience and pitfalls in the comments.

Next time, let’s dive into advanced pgvector usage: choosing between IVFFlat and HNSW indexes for different scenarios, and how to tune parameters for faster queries.