If you’ve worked on more than one Retrieval-Augmented Generation (RAG) project, you’ve probably run into the same annoying pattern: every project ends up with its own little vector store, its own embedding logic, its own duplicate code for chunking files, and its own inconsistent way of tracking what’s actually been indexed. I got tired of that, so I built a centralized vector database service that every project in my organization can plug into. One backend, one embedding model, one clean set of endpoints — and every project gets its own isolated, admin-controlled storage space.
Here’s how it works.
When you’re running multiple RAG-powered projects at once, a few pain points show up fast:
I wanted one system that solves this once, for everyone.
Instead of giving each project its own standalone vector database, I built a shared service where:
This means projects don’t need to know anything about vector databases, embedding models, or similarity search internals. They just send text in and get relevant results back.
Here’s the high-level flow: Press enter or click to view image in full size
In plain terms:
Each project is fully sandboxed. Nothing bleeds across storage directories.
Every project follows the same simple lifecycle:
A new, isolated space is created for the project. Invalid or unsafe directory names are automatically rejected.
Upload a document (PDF, TXT, DOCX, or Markdown) and it comes back as clean, ready-to-embed text chunks. This step doesn’t store anything yet — it just prepares the data.
The chunks get embedded and stored. If the project’s index doesn’t exist yet, it’s created automatically. If it does exist, new vectors are simply appended. Duplicate sources are automatically prevented.
A query comes in, gets embedded the same way, and the service returns the top-k most similar chunks — along with which source file they came from. A similarity score threshold filters out weak matches.
At any point, an admin can:
The real win here isn’t the vector search itself — FAISS and sentence-transformers are well-understood tools. The win is centralization with isolation:
It turns “set up a vector database” from an infrastructure task into a two-endpoint integration for whoever’s building the next project.
A few directions I’m considering for this pipeline:
If you’re building multiple RAG projects and keep rebuilding the same vector storage logic every time, this pattern — one shared service, isolated storage per project, centralized admin control — is worth stealing. Have you built something similar, or run into different tradeoffs with multi-project RAG infrastructure? I’d love to hear how you approached it.