expectedwrong hindsight

RAG for Database Rows, Without the Azure Tax

A prebuilt pattern for doing retrieval over tabular data that nobody told you was already done.

2 min read 265 words #rag #postgres #pgvector #llm #databases
hindsight — nailed it

pgvector plus SQL filtering became the standard pattern for structured data RAG. The "without the Azure tax" angle was prescient — most teams ended up doing exactly this with vanilla Postgres.

Most RAG demos assume you have a pile of PDFs. You chunk the PDFs, embed the chunks, stuff them in a vector store, retrieve on query — fine, we've all seen it. The interesting problem, the one that actually comes up at work, is when your data lives in a database. Rows. Columns. Foreign keys. Stuff that doesn't want to be chunked.

The Azure-Samples/rag-postgres-openai-python repo solves this, and despite the name badge it doesn't actually require Azure. Swap in any OpenAI-compatible endpoint and a local Postgres instance and you're running. The "Azure" in the title is marketing; the architecture underneath is just pgvector doing semantic search over row embeddings, combined with ordinary SQL filtering so you can still ask structured questions without hallucinating a WHERE clause.

The pattern it demonstrates: embed your rows, store the vectors in Postgres alongside the actual data, query with a hybrid of similarity search and filters, pass the retrieved rows to the model as context. No specialized vector database. No new infrastructure dependency. The thing you already have — Postgres — is doing the heavy lifting via pgvector.

What makes it worth noting is that someone already built the scaffolding. Data ingestion, embedding pipeline, query layer, the connective tissue between "here is a natural language question" and "here are the relevant rows from your database." Pre-assembled and readable enough to actually learn from.

Tabular RAG is an underserved problem. Most of the ecosystem is document-shaped. This is a clean, working answer to the row-shaped version, and it's sitting there on GitHub with a misleading corporate prefix, quietly doing the job.