This note is for two kinds of builders.
First, developers beginning their AI journey who want to understand what kinds of AI systems they can realistically build today using familiar tools. Second, engineers who already have AI applications in development or in production and want concrete ways to improve them.
The core claim is simple: if you already know PostgreSQL, you already know enough to build serious AI systems.
Modern AI systems no longer require teams of researchers or specialised databases. Advances in large language models and open-source tooling have shifted the centre of gravity toward application developers.
The most common builder today is not a machine learning researcher, but a full-stack or backend engineer who uses AI to build useful products. This is the rise of the AI engineer: someone who integrates models into systems rather than training models from scratch.
PostgreSQL fits naturally into this shift. If your organisation already uses Postgres, you can build AI features without introducing entirely new infrastructure.
Vector data is simply a compressed numerical representation of other data: text, images, audio, or code. These vectors are produced by embedding models and live in high-dimensional space where semantic similarity becomes measurable.
A vector database stores and searches these vectors efficiently. Its value in AI systems comes from enabling retrieval-augmented generation (RAG), where relevant context is fetched and passed to a language model at inference time.
With vectors, language models can work with your data: documentation, tickets, transcripts, or internal knowledge.
PostgreSQL’s extension system is what makes this possible. Extensions add specialised capabilities without sacrificing relational guarantees.
These extensions are open source and designed to work together. Installing higher-level extensions automatically pulls in pgvector as a dependency.
Using PostgreSQL for AI systems reduces architectural complexity. You avoid synchronising data across systems and maintain a single source of truth.
Vectors live alongside metadata, permissions, timestamps, geospatial fields, and business logic. This enables richer queries and simpler reasoning about system behaviour.
Performance is not sacrificed. At scale, PostgreSQL can match or exceed specialised vector databases for many workloads, especially when filters and joins are involved.
Vector indexes trade exactness for speed. Below roughly 100,000 vectors, brute force search is often sufficient. Beyond that, approximate nearest neighbour indexes become valuable.
Choosing an index is an engineering decision driven by data size, update frequency, filtering needs, and cost constraints.
Building useful AI systems requires more than wiring up a demo. Evaluation-driven development is a practical mindset for continuous improvement.
Start with a fixed evaluation set: real user questions your system must answer. Measure changes over time as you swap models, embeddings, or retrieval strategies.
Decompose failures. Is retrieval wrong? Is the agent choosing the wrong tool? Is the SQL query incorrect? Most failures are architectural, not model-related.
PostgreSQL is not just a relational database. With the right extensions, it becomes a foundation for modern AI systems.
The advantage is not novelty, but leverage. One system. One language. Clear trade-offs. Fewer moving parts.
Understanding these primitives allows you to move beyond toy demos and build AI systems that survive contact with production.