6 posts tagged with "pgvector"

Retrieval-augmented chat is the demo everyone wants and almost nobody ships cleanly. The interface is easy. The plumbing is not. You need a vector store, somewhere to keep the documents, an inference endpoint that does not leak your data, and an app that knows how to reach all three. That is a database, a bucket, an API key, a handful of environment variables, and a firewall rule or two, all wired by hand before you see a single answer.

The rag-chatbot stack collapses that into one launch. Pick it, accept the cost preview, and a few minutes later you are chatting over your own data on infrastructure you own, resident in Europe.

Every platform you have ever shipped on hands you a bag of parts. A database here. A bucket there. An auth provider, a connection string, a set of S3 keys, a firewall rule, an environment variable to remember on Monday. Each part is real and each part works, but none of them know about each other. The wiring is the project. You spend the first afternoon copying credentials between dashboards before your app renders a single useful screen.

Today we ship the opposite of a bag of parts. create-foundry-app is live. One command scaffolds a Next.js app that already declares what it needs. One deploy provisions every one of those resources on FoundryDB, wires them together, and injects the credentials into the running app. No connection strings to copy. No firewall rules to open. No API keys to paste. You write the app and you ship the wired whole, resident in Europe, in one command and one deploy.

And because we know the first question every serious developer asks: it is open-source, it is MIT, and every primitive maps to an open standard, so the same app runs anywhere. You own the convenience, not a lock.

Every managed platform you have ever used hands you a bag of parts. A database here. A bucket there. An API key, a network rule, a connection string, an environment variable. Each one is a primitive, and each one is yours to wire together. The pitch is "look how much you can build." The reality is an afternoon of plumbing before you see a single useful screen, and a config file that only you understand by Friday.

Today we flip that around. FoundryDB Stacks is live. A stack is the finished thing. One button stands up a complete, production-ready application, composed of those same primitives but already wired together, already metered, in minutes, and resident in Europe. You do not assemble the app. You launch it.

Your data already lives in Europe. Your databases run in European zones, your backups stay in European object storage, and your compliance story is clean right up until your application calls a model. Then a prompt full of customer data crosses the Atlantic on a key someone pasted into an environment variable, with no ceiling, no metering, and no answer to the question "where did that text actually go?"

Today we close that gap, and we do something bigger than close it. Three features ship together: vector search as a service over pgvector, embedding pipelines that run as real jobs with schedules and run history, and a managed inference proxy that puts one governed, OpenAI-compatible endpoint in front of OpenAI, Anthropic, Mistral, and Azure OpenAI. Together they make FoundryDB the European AI Data Platform: the one place where your data, your embeddings, and your model calls live under a single set of controls.

Retrieval-Augmented Generation (RAG) has become the standard approach for grounding LLMs in factual, up-to-date data. Instead of fine-tuning a model on your corpus (expensive, slow, stale within weeks), you retrieve relevant context at query time and feed it to the LLM alongside the user's question.

In 2026, RAG is no longer experimental. It powers customer support bots, internal knowledge search, legal document analysis, and code assistants at thousands of companies. The architecture has stabilized around a common pattern: ingest documents, generate embeddings, store vectors, retrieve at query time. What varies is how well you operate the infrastructure underneath.

This post walks through building a production RAG pipeline on FoundryDB using PostgreSQL with pgvector, Kafka for document ingestion, and Valkey for result caching.

Every RAG system needs the same boring middle layer: watch a table for changes, call an embedding API, write vectors back, handle retries, manage batches, build indexes, schedule cron jobs, and pray nothing drifts out of sync at 3 AM. FoundryDB's managed embedding pipelines eliminate that entire layer. You configure a pipeline, and your PostgreSQL data gets auto-vectorized with an HNSW index, ready for similarity search.

No ETL scripts. No cron jobs. No model orchestration code.