PostgreSQL, the Preferred Companion for Vibe Coding: AI Agent Development's 'Grand Simplicity'

Based on Xiao Shaocong's presentation at HOW 2026. Xiao Shaocong is a co-founder of the Cortrix.AI semantic storage project; a former president of the China PostgreSQL Association and chair of its Chinese community; a member of the IvorySQL Expert Advisory Committee; and a former senior RDS product expert at Alibaba Cloud and storage industry marketing expert at Huawei, focused on database technology, AI data processing, and open-source development.

Over the past two years, I have held firmly to one conviction: in today's development model powered by AI and large language models, PostgreSQL is bound to become the preferred companion of every AI project. Of course, I am not saying PG can do everything and serve as the eternal foundation — at some point, certain workloads and business scenarios may indeed require migrating data in a particular shape to dedicated databases. But as a starting point, PG is, without a doubt, the best choice.

Today I will expand on four topics: first, our pain point — Token anxiety; second, how "One SQL" lets you get twice the result with half the effort; third, how a unified data plane lets AI work with "no blind spots"; and fourth, a discussion of where the boundaries lie for PG as the first choice for AI.

1. Vibe Coding's Pain: System Complexity as a "Token Incinerator"

When we develop a system, a single database is usually enough at the beginning — the business is not that complex. But as you go along — whether you are developing an AI application or any other kind — you find yourself needing JSON capabilities, search capabilities, and all sorts of AI-related features. Each addition is a new form of data, and every decision looks perfectly correct and reasonable in the moment.

But what is the result? Your system grows from 1 database into 5, or even more.

You bring in MongoDB for documents, Elasticsearch for search, and Milvus for vectors — it looks like you are being responsible, choosing the best product in the industry for your team. But here is a question everyone should think about: has your business actually gotten off the ground? Your project may have only just begun, and you have already saddled yourself with the most complex architecture — that is not really appropriate.

What is more, in the process of Vibe Coding, the price of multiple databases is a sharp explosion in Token consumption:

• Different databases have different syntaxes, so the AI has to learn multiple query languages
• Data must be synchronized among multiple systems, so the AI has to write and maintain ETL logic
• Cross-system queries are broken into multiple steps, and every step consumes Tokens
• The context window gets overwhelmed, and the model is outright "dumbed down"

Is this Vibe Coding? It is more like a Token incinerator.

What is the solution? Solve all the problems with a single database within one boundary. And that database is PostgreSQL.

2. One SQL, Twice the Results: Field Validation with 50,000 Lines in 10 Days

Last November, I ran an experiment: using a purely AI-assisted development approach, I completed a project called OntologyAlpha in 10 days, generating about 54,000 lines of code in total, of which about 11,300 lines of effective code finally went live.

This project is an ontology-related system, and its underlying layer needs to handle four kinds of data:

• JSON: the input and output of AI, and the information exchanged between the frontend and backend
• Vector: the semantic representation of text, used for similarity search
• Graph: tracking the upstream/downstream associations of knowledge points and managing their hierarchy
• Time-series: recording the chronological order of contextual interactions

Architecturally, the storage layer is PostgreSQL's native multi-model storage, with Async Workers and a Python secure sandbox above it, and a Next.js visual workbench on top — all of the code was generated by AI, and I did not write a single line myself.

How it was developed: I used the Gemini model in Google AI Studio as the "Chief Data Officer / CTO", responsible for architecture planning and task breakdown; then I used Cursor (free tier, default model) for the concrete code implementation. The total investment was 82 working hours, roughly 10 person-days.

What was achieved:

• CPU/memory device monitoring, supporting both precise search and fuzzy semantic search
• Elementary-school math textbook knowledge vectorized into a knowledge graph (no dedicated graph database was used — two relational tables simulated the graph structure)
• PDF documents (such as Singapore's talent policy) with automatic extraction of keywords and business relationships, forming upstream/downstream chains
• Python sandbox integration: when the CPU overheats, state changes in the upstream chain are triggered automatically

The key SQL looks like this:

-- One SQL that simultaneously does: JSON extraction + relational graph traversal + vector similarity search
SELECT ...
FROM ...
WHERE name->>'xxx' = '...'   -- JSON field extraction
  AND relation_type = '...'   -- relational graph logic
  AND embedding <-> '...'     -- vector similarity

One SQL handles a combined query across three data models. In PG, transactions, permissions, and backups all belong to one unified system, so there is no need to worry about cross-system data consistency.

Throughout the entire development process, I used only the most basic AI plans — Google Gemini at $20/month and Cursor's free plan. Token consumption stayed very manageable.

3. A Unified Data Plane Keeps You One Step Ahead: AI Coverage with "No Blind Spots"

Many people complain that PostgreSQL is no good at vectors — memory consumption is too high, and it is hard to scale to hundreds of millions of records.

Here I want to recommend a project: pgvectorscale, developed by the TimescaleDB team. It puts the vector index on disk and, through DiskANN + quantization, breaks through the memory limit, supporting ultra-large-scale vector retrieval while substantially lowering cost.

But what I want to emphasize is: PG's advantage is not in being the strongest at any single capability. If your system must handle vectors at the scale of more than 100 million with extremely high QPS, then yes, you should choose a dedicated vector database. But when your business needs to manage relational, vector, JSON, time-series, graph, and other data models in combination, PG is an all-round player that scores around 80 in every capability.

What is the advantage of combining them? It dramatically reduces system fragmentation and significantly lowers development and operations complexity.

In a multi-database hybrid architecture, your application has to manage all of this by itself:

• Relational databases use SQL, while a vector database may not support SQL at all
• Do you need transactions between the two systems? How is consistency guaranteed?
• After introducing ETL, the application has to worry about ETL latency — which data is trustworthy and which has gone stale?
• How are permissions unified? How are backups unified?

Once you have to manage all of that, Vibe Coding's consumption, accuracy, and output quality all become terrible.

Inside PG, by contrast, the value of a unified data plane is:

• 1 Network Hop: the application accesses only one database
• 1 set of transactions: all operations are completed within the same transaction
• 1 set of permissions: unified data access control
• 1 set of backups: a unified disaster-recovery system

The losses caused by system complexity are often greater than the gains of pure single-point performance. Many times, you are paying the bill for a multi-system architecture.

4. PG Is AI's "Love" — the First Choice: Clear Boundaries, Greater Peace of Mind

I like PG this much — so when should you consider introducing a dedicated database?

My own advice is this — use PG to solve 80% of the problems first and build out business capabilities quickly. Once you have earned your first dollar, then think about whether to migrate.

In concrete terms:

Once the boundaries are clear, you will dare to use it even more.

PG 19 will natively support better graph queries. At this stage, you can also use the AGE extension, or — like me — "cobble together" a graph structure out of a few relational tables. For most AI application scenarios, that is entirely sufficient.

Conclusion: Fewer Systems, Rather Than Stronger Ones

In the AI era, I believe everyone should be an architect. But from an architectural way of thinking, the goal should be fewer systems, rather than stronger systems.

There used to be a way of thinking: the more complex I make the architecture, the less willing the boss is to fire me. But now that AI has arrived, if your boss wants to fire you, it is not because of AI but because the business is not being run well.

Let go of that burden. What truly has value is:

PostgreSQL is the default starting point, not the final destination.

Start with PG, validate the business model quickly, save Tokens, save management time, and put your energy into monetizing the business. Only after the business is stably profitable and you hit a clear technical bottleneck should you carefully evaluate whether to bring in a dedicated database.

A clean and simple architecture is the architecture with the greatest flexibility for the future.