Vector Databases Are a Billion-Dollar Scam (And PostgreSQL Just Killed Them For Free)

If you walked into a tech meeting over the last two years and used the words AI, RAG (Retrieval-Augmented Generation), and Vector Database in the same sentence, a venture capitalist in the room would probably write you a multi-million dollar check on the spot.

Dedicated vector databases (Vector DBs) like Pinecone, Milvus, Weaviate, and Qdrant have raised billions of dollars in just the last few years. The narrative was flawless: If you want to teach Large Language Models (LLMs) your company’s proprietary data, traditional databases are useless. You had to convert your data into numerical arrays called embeddings and use entirely new, space-age databases built from the ground up just to store them.

But there was a massive elephant in the room that Silicon Valley desperately avoided talking about. A 30-year-old, boring, reliable, and completely free open-source giant quietly made its move in the background.

With the pgvector extension, PostgreSQL pulled the plug on this billion-dollar industry overnight—and it did it for free.

But how? Let’s ruthlessly pop this billion-dollar hype bubble through the lens of engineering, data science, and architectural realities.

1. The Illusion Vector Databases Sell

For an AI to understand a word, sentence, or document, it must be converted into a mathematical format (an embedding). For example, a piece of text is transformed into a 1536-dimensional array of numbers.

The fundamental purpose of vector databases’ existence is to perform similarity searches across these massive numerical arrays. In technical terms, calculating the distance between two vectors usually relies on Cosine Similarity or Euclidean distance.

Mathematically, an AI finds the closest data to your query using this simple equation:

Dedicated vector database companies rightfully claimed: Traditional relational databases (SQL) cannot compute this equation across millions of rows in seconds. You need specialized indexing algorithms for that.

And they were right. Until pgvector entered the stage.

2. The Elephant in the Room: An Operational Nightmare

There is an unwritten rule in software architecture: Every new technology you add to your system exponentially increases maintenance costs and the probability of bugs.

If you use a dedicated vector database (like Pinecone), your architecture becomes poisoned by the following workflow:

1. Your customer data lives in PostgreSQL.
2. The vector embeddings of that data live in the Vector Database.
3. When a user deletes or updates their data, you are forced to synchronize these two completely different databases.

Legendary engineer and author of Designing Data-Intensive Applications, Martin Kleppmann, explains this Distributed Systems Nightmare perfectly:

Keeping different data systems synchronized is one of the hardest and most dangerous problems in software engineering. Data inconsistency will eventually bring your system to its knees.

What investors don’t tell you is this: Integrating a new database without ACID (Atomicity, Consistency, Isolation, Durability) guarantees into your system just to make your AI app run faster is playing Russian roulette with your data integrity.

3. PostgreSQL and the pgvector Checkmate

Around May 2023, the PostgreSQL ecosystem announced an open-source extension called pgvector. With a simple SQL command (CREATE EXTENSION vector;), it instantly transformed the world's most reliable database into an AI engine.

But how was the speed? Initially, it used an indexing method called IVFFlat, which was decent. However, the real revolution happened when the HNSW (Hierarchical Navigable Small World) indexing algorithm was integrated into pgvector.

Why Did HNSW Change Everything?

Introduced to the literature in a 2018 paper by Yu. A. Malkov and D. A. Yashunin, the HNSW algorithm is the world’s most advanced Approximate Nearest Neighbor (ANN) search method, capable of performing similarity searches across billions of vectors in microseconds.

The secret sauce that made dedicated vector databases so fast was already HNSW. And PostgreSQL simply baked this algorithm directly into its core.

Now, you could run an AI semantic search using this SQL query:

SELECT id, document_text 
FROM documents 
ORDER BY embedding <=> '[0.1, 0.2, 0.3...]' 
LIMIT 5;

(This simple block of code fetches the 5 most semantically similar documents to the user’s query in milliseconds.)

4. The 99% Rule: You Are Not Meta or Google

The final stronghold of dedicated vector database companies is this argument: Sure, but pgvector slows down when you have billions of vectors. We are built for petabytes of data.

This is exactly where the biggest lie of the VC bubble lies.

In his famous manifesto Choose Boring Technology, which has become a cult classic in the industry, software engineer and architectural consultant Dan McKinley warns engineers:

99% of the problems you face do not require a cool, new technology. What you need are boring technologies whose limits and failure modes have been known for decades. Spend your innovation tokens on the actual product that adds value to the user, not on the infrastructure.

Real-world statistics are brutal: For 99% of companies, their entire dataset is small enough to easily fit into a standard PostgreSQL table (a few hundred million rows). You only need completely custom hardware and dedicated vector infrastructure if you are operating at the scale of Meta, Google, or OpenAI. For everyone else, pgvector is not just sufficient; it is architecturally superior.

• Because you can use JOIN operations. (e.g., Give me the AI-matched documents, BUT only from users who became premium members in the last month.) Relational queries like this are sheer torture in dedicated vector databases.
• Because you can use Row-Level Security (RLS).
• Because you already know exactly how to back up, monitor, and scale PostgreSQL.

Conclusion: NoSQL History Repeating Itself

If you have been in this industry long enough, you will remember this exact story. In the early 2010s, when the Big Data hysteria erupted, investors poured billions into NoSQL databases like MongoDB and Cassandra. Articles everywhere screamed that The era of relational databases (SQL) is over

So, what happened? PostgreSQL integrated the JSONB data type into its system. It offered the flexibility of NoSQL combined with the unshakeable reliability of SQL — for free. NoSQL didn’t die, but it stopped being the default choice for 99% of us.

Today, in the age of AI, history is repeating itself word for word. Vector databases won’t completely disappear; they will survive for highly specific, massive-scale niche problems (like Netflix’s recommendation algorithm).

But for 99% of companies building a new AI startup, developing a RAG architecture, or adding semantic search to their system, buying a dedicated vector database is nothing more than a billion-dollar marketing illusion.

Everything you need is already waiting for you inside that old, boring, and free database. Welcome to the victory of PostgreSQL.

References & Further Reading

• Kleppmann, Martin. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O’Reilly Media, 2017.
• Malkov, Yu. A., & Yashunin, D. A. Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence, 2018.
• McKinley, Dan. Choose Boring Technology. mcfunley.com, 2015.
• PostgreSQL Global Development Group. pgvector: Open-source vector similarity search for Postgres. (github.com/pgvector/pgvector)
• Moore, Gordon E. (Broader context on hardware/software evolution and industry adaptation beyond Moore’s Law).