Vector Database Hosting in Romania

What a working RAG setup needs

A chatbot that answers from your company documents needs more than a vector store. We build the whole chain: extraction from PDFs, contracts or internal pages, chunking with controlled overlap, embedding generation, indexing in Qdrant and hybrid search that combines semantic closeness with exact keyword matching. We add metadata filters, so a user never receives fragments from documents they have no right to open.

• A resumable ingestion pipeline, with re-indexing when documents change
• Hybrid search: vectors plus lexical matching for exact terms
• Metadata filters by department, client or confidentiality level
• Retrieval quality measured on a set of real questions

Best practices we apply to RAG

RAG projects rarely fail because of the model. They fail because of the data and the access rules. We apply this list on every delivery and leave it in your documentation, together with the question set we use to measure answers. Without a measurement agreed at the start, every change of model, chunking or search parameter looks like an improvement, and nobody on the team can prove that it is one.

• Private network or VPN only, plus an API key for every consumer
• Regular snapshots of the collections, with restores tested
• Vector quantisation where it cuts memory without hurting relevance
• Mandatory metadata filtering, so answers respect access rights
• Personal data pseudonymised before indexing when the purpose does not need it

EU data residency, the AI Act and GDPR

The main reason Romanian teams bring their RAG onto their own infrastructure is control over the data. Documents stay in Frankfurt, embeddings can be generated locally on GPU servers, and if you still use an external model we show you exactly which fragments leave and which stay. You receive an Article 28 processing agreement and SCCs for transfers, and our operation is aligned with ISO 27001. For AI Act discussions, being able to document the data path matters.

Included hours and GPU servers

Installation, the first indexing run and tuning come out of the monthly hours in your plan: 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, 10 h on GPU servers. You request them in the client panel under DevOps Services and propose a deadline. For locally run embedding models we recommend a GPU server, where the 10 h quota usually covers setup and re-indexing. Hours do not roll over; anything above the quota is billed separately.

How we work

1. Request it in the panel

   Tell us which documents you want to query, in what volume and who must have access, then propose a deadline in the client panel.

2. We scope the work

   We choose the vector database and the embedding model that fit your volume, define the evaluation question set and estimate the hours.

3. We build it and measure relevance

   We index the documents, enable hybrid search and metadata filtering, then run the evaluation and adjust chunking until the results are stable.

4. Handover with documentation

   You receive the pipeline in your own repository, the collection schema, the access rules, the re-indexing procedure and the evaluation report.

Use cases

Technology stack

• Qdrant
• ChromaDB
• pgvector
• PostgreSQL
• Ollama
• vLLM
• LiteLLM
• Prometheus
• Grafana

Frequently asked questions

• Qdrant vs Chroma: which one is better for RAG?

  Chroma is convenient for prototypes and small collections, and installs in minutes. Qdrant holds up better in production, with fast metadata filtering, quantisation, snapshots and replication. When a project moves past the demo stage, we start directly on Qdrant.

• What is a vector database?

  It stores vectors, the numeric representations of text or images, and quickly finds the items closest to a query. That enables search by meaning rather than identical words, and it is the layer every RAG system sits on.

• Can I self-host a RAG pipeline in the EU for GDPR?

  Yes. The vector database and the documents stay on your servers in Frankfurt, and the embedding model can run locally on a GPU server. If you choose an external model to write the answers, we document exactly which fragments are sent.

• pgvector or Qdrant?

  pgvector fits when you already run PostgreSQL and have tens of thousands of chunks: one system to administer and one backup. Qdrant is better at large volumes, complex metadata filters and steady search traffic, because it is designed for exactly that.

• Is self-hosting Qdrant cheaper than a managed cloud?

  Often, once the collection is large and traffic is steady, because you pay for a server instead of per-vector usage. You also take on the operations, which is what the included hours cover. We size memory with quantisation first.

• Do I need a GPU server for embeddings?

  Not always. For rare re-indexing a VPS is enough. A GPU pays off for frequent re-indexing, very large document sets, or when you also want to run the answer-generating model locally, so that nothing leaves your infrastructure.