Postgres for AI Apps: A Practical Primer
This is a sample post. Real, original write-ups are being cooked up right now, brewing slowly, but properly.
Postgres for AI Apps: A Practical Primer
Most AI apps don't need a dedicated vector database. Postgres with the
pgvector extension handles relational data and similarity search in one
place.
Quick answer: install
pgvector, add avectorcolumn, index it with HNSW or IVFFlat, and query with the<->distance operator — no separate vector database to operate.
Why one database beats two
Running a vector database alongside Postgres means two systems to back up,
secure, and keep in sync. pgvector collapses that into one.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id serial PRIMARY KEY,
content text,
embedding vector(1536)
);
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
Where it starts to strain
At very large scale (tens of millions of vectors, sub-10ms latency requirements), a dedicated vector database may still win — but that's a later problem for most projects, not a starting one.
Key Takeaways
- Start with Postgres + pgvector; it's almost always enough at first.
- HNSW indexes trade a bit of build time for much faster queries.
- Fewer moving parts means fewer things that can silently drift out of sync.
Related Reading
Related reading
Getting Started with Pydantic for LLM Outputs
Why raw text out of an LLM is a liability, and how Pydantic models turn it into something your code can actually trust.
Building a Typed MDX Content Engine for a Zero-Cost Blog
How this site reads blog posts straight from the filesystem at build time — no database, no CMS, fully typed.
What Is RAG, and Why It Matters
Retrieval-Augmented Generation in plain terms — what it actually does, when it's worth the added complexity, and when it isn't.