{"version":"v1","site":{"name":"expectedwrong","url":"https://expectedwrong.com"},"links":{"collection":"https://expectedwrong.com/api/public/posts","rss":"https://expectedwrong.com/rss.xml","llms":"https://expectedwrong.com/llms.txt"},"post":{"slug":"rag-postgres-tabular-rows","title":"RAG for Database Rows, Without the Azure Tax","subtitle":"A prebuilt pattern for doing retrieval over tabular data that nobody told you was already done.","url":"https://expectedwrong.com/rag-postgres-tabular-rows","api_url":"https://expectedwrong.com/api/public/posts/rag-postgres-tabular-rows","published_at":1722686400,"published_at_iso":"2024-08-03T12:00:00.000Z","updated_at":1775309946000,"updated_at_iso":"+058227-05-02T19:40:00.000Z","tags":["rag","postgres","pgvector","llm","databases"],"excerpt":"A prebuilt pattern for doing retrieval over tabular data that nobody told you was already done.","meta_description":"A prebuilt pattern for doing retrieval over tabular data that nobody told you was already done.","reading_time_minutes":2,"word_count":265,"engagement":{"signals":0,"counterpoints":0},"body_markdown":"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.\n\nThe 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.\n\nThe 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.\n\nWhat 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.\n\nTabular 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.\n","body_text":"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.","hindsight":{"verdict":"right","note":"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.","links":[],"at":1739980800,"at_iso":"2025-02-19T16:00:00.000Z"}}}