{"slug": "why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag", "title": "Why Twio Chose Vertex AI Search over pgvector for Production RAG", "summary": "Twio, an AI SaaS for loan brokers, migrated its production RAG system from pgvector to Vertex AI Search after scaling challenges revealed that vector storage alone was insufficient for handling messy broker documents, emails, and attachments. The company found that Vertex AI Search reduced engineering overhead by managing OCR, chunking, indexing, and retrieval, making it cheaper overall despite higher direct costs. Twio's experience shows that starting with a simple tool like pgvector to learn fast, then moving to a managed solution like Vertex AI Search for production reliability, is a pragmatic evolution.", "body_md": "When we first built RAG at Twio, pgvector was the obvious pick. Our business data was already in PostgreSQL, and dropping embeddings into the same database was the fastest path to a working product.\n\nFor the first version, that was right. As we scaled, the problem stopped being \"how do we store vectors?\" and became \"how do we reliably understand thousands of broker documents, emails, and attachments in production?\" That changed the answer. Today, Vertex AI Search is our main retrieval layer.\n\nTwio is an AI SaaS for loan brokers. A single client case is a mess of fragmented information:\n\nThe AI needs to answer questions like:\n\nIf retrieval is weak, the answer is weak. If indexing lags, context is missing. If parsing is wrong, the model sees the wrong evidence. RAG isn't a feature on the side — it's the memory layer of the product.\n\nTwio is a multi-tenant SaaS, so retrieval can't just return \"similar content\" — it has to return similar content scoped to the right user, client, application, or file. pgvector made that trivial: embeddings sat next to the business records, joined cleanly, and filtered with plain SQL.\n\nThe early wins were real:\n\nIt let us build the first version quickly and learn from actual usage. That matters more than people give it credit for.\n\npgvector didn't fail. It did exactly what it's designed for. The issue was that vector storage is only one slice of the RAG pipeline, and pgvector left every other slice to us:\n\nA clean PDF is easy. A scanned bank statement isn't. An email body is easy. An email with five attachments, lender forms, tables, and partial OCR isn't. A demo dataset is easy. A real broker workspace with years of historical emails isn't.\n\nWith pgvector, every weakness in that pipeline was ours to fix. When retrieval quality dropped, the suspect list ran all the way from OCR through chunking and embedding to vector distance, SQL filtering, ranking, and DB performance. The extension is simple. The production RAG system around it isn't.\n\nThe cost shifted from cloud bill to engineering time — and engineering time was the constrained resource.\n\n| Scenario | pgvector | Vertex AI Search |\n|---|---|---|\n| Clean text PDF | We own extraction, chunking, embedding, storage, search | Vertex handles most of the indexing and retrieval workflow |\n| Scanned document | We build or integrate OCR ourselves | Vertex absorbs much of the document-processing logic |\n| Broker asks a document question | We own query design, ranking, filtering | Managed search with stronger out-of-the-box quality |\n| Attachment bursts | Postgres carries more search and indexing load | Search workload lives outside the main database |\n| Debugging | Excellent SQL visibility, but many custom layers to inspect | Less low-level control, but far less custom infra to debug |\n| Cost | Lower direct service cost | Higher service cost, lower engineering and maintenance cost |\n| Production readiness | Significant custom work required | Easier to operate as a managed layer |\n\n**pgvector was cheaper as a database extension. Vertex is cheaper as a product decision.** The cloud bill is one input; engineering time, reliability, and iteration speed are the bigger ones at our stage.\n\nTwio's RAG problem is document-heavy. We aren't searching short snippets — we're dealing with messy broker PDFs, scans, forms, tables, and forwarded attachments. Vertex helps in four concrete ways:\n\nVertex isn't free, but the alternative isn't either. Building OCR, indexing, ranking, monitoring, and tuning ourselves has its own bill — paid in engineer-weeks.\n\npgvector is still a strong choice when:\n\nFor us, it was the right first implementation — and it taught us what retrieval the product actually needed. It may stay in the stack for internal or fallback use cases.\n\nThe lesson from Twio's RAG evolution is simple:\n\n**Start with the tool that helps you learn fastest. Move to the tool that helps you operate best.**\n\npgvector got us to a working RAG system quickly. As the product matured, the real challenge shifted to document processing, indexing quality, and operational reliability — and at that point, Vertex AI Search became the better fit. It costs more as a service and less as a system to maintain. For a SaaS at Twio's stage, that's the trade that matters.", "url": "https://wpnews.pro/news/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag", "canonical_source": "https://dev.to/twio_ai/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag-51jm", "published_at": "2026-06-22 00:00:58+00:00", "updated_at": "2026-06-22 00:25:29.185664+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-products", "ai-infrastructure", "developer-tools"], "entities": ["Twio", "Vertex AI Search", "pgvector", "PostgreSQL"], "alternates": {"html": "https://wpnews.pro/news/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag", "markdown": "https://wpnews.pro/news/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag.md", "text": "https://wpnews.pro/news/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag.txt", "jsonld": "https://wpnews.pro/news/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag.jsonld"}}