The same AI chat message used to require two writes — one into MySQL, one into Milvus (a specialized vector database). If either failed, you got the awkward state of "data exists but can't be searched" or "searchable but inaccessible." PostgreSQL (a long-standing open-source relational database) with the pgvector extension now handles both in a single table.

This deserves our attention as engineers — it means infrastructure costs for AI long-term memory could be cut significantly.

What this is

For AI to retain chat history long-term, two capabilities must coexist: relational queries (retrieving data by user, session, time) and semantic search (finding messages with similar meaning). The old engineering consensus was "two databases": MySQL handles structured data, Milvus handles semantics.

The problem isn't performance — it's "dual-write": the same message written to two stores, with either failure causing data inconsistency — the message exists in the database but can't be found, or vice versa. Solving this requires transactions, retry queues, and compensation tasks — essentially building a distributed system just to store chat history.

PostgreSQL's solution is direct: add an embedding (vector) column to the message table, and use the pgvector extension for semantic search. One table, one SQL dialect, one write — relational queries and vector search share the same data.

Industry view

Supporters' judgment is clear: simpler architecture, lower ops costs, especially friendly to small teams. One full-stack engineer plus one PG instance can now build ChatGPT's memory system — previously requiring backend, data, and platform teams collaborating.

But opposition is equally real:

  • pgvector's search speed at hundreds-of-millions-of-vectors scale still typically lags behind specialized solutions like Milvus
  • Migration costs for legacy systems are high — large companies' MySQL/Milvus stacks won't be replaced overnight
  • Single database means single point of failure — if PG goes down, both relational and vector data become unavailable simultaneously, versus the old setup where only half would fail

Our pragmatic conclusion: PG + pgvector is the better choice for SMBs and mid-scale AI products, but not the endgame of "database unification."

Impact on regular people

For enterprise IT:When evaluating in-house AI product builds, the single-PG approach deserves to be the baseline — engineering headcount and ops investment will be significantly lower than the dual-database route.

For individual careers:Database requirements for full-stack engineers are rising — not just CRUD (create, read, update, delete), but also understanding vector embeddings (converting text to numbers), index principles, and query optimization.

For the consumer market:AI chat products' "memory" features will become more stable and cheaper — the frustrating experience of "what we just talked about can't be found" caused by write failures will diminish.