You do not need a vector database to ship AI in Rails
Postgres was retrieving relevant records before retrieval was augmented.
Somewhere in the last two years, “we want AI to answer questions from our data” became “we need a vector database.” For most Rails teams, that is a purchase in search of a problem.
Walk through what retrieval actually needs to do for a typical internal AI feature: given a question, find the handful of records that are relevant, and put them in the prompt. Postgres has been doing the first half of that job since before it was called retrieval.
- Full text search (
tsvector, or pg_search) covers most support, documentation, and lookup use cases, because users and tickets mostly share vocabulary. - pgvector adds embeddings inside the database you already run, already back up, and already know how to query, when you genuinely need semantic matching.
- A join is still the best retrieval when the question is “what did this customer order,” which is what a surprising fraction of “AI questions” turn out to be.
The dedicated vector database earns its place at a scale most mid market products never reach: tens of millions of embeddings, high write churn, latency budgets in single digit milliseconds. Below that, it is a second data store to operate, secure, back up, and keep consistent with Postgres, purchased before anyone measured whether tsvector was good enough.
Measure first. Take fifty real questions, run them against plain full text search, and count how often the right record lands in the top five. That number is usually the end of the vector database conversation.
The retrieval quality conversation worth having is about your data: inconsistent tags, stale macros, duplicated docs. No index type fixes that. That is exactly the kind of finding our AI Readiness Assessment puts numbers on before you commit build budget.
Next in the series: wiring the agent loop with background jobs.