Introducing AI OS for Business & School — our most powerful products yet.Explore →
App Corp
Full-service software engineering
Engineering your experience…
App Corp
Full-service software engineering
Engineering your experience…
Vector search without the infrastructure complexity
App Corp builds RAG systems using PostgreSQL and pgvector for knowledge bases, document search, and semantic retrieval. Hybrid search, multi-tenant isolation, and production-grade indexing.
We build RAG systems on PostgreSQL with the pgvector extension. The architecture:
Document ingestion pipeline: documents are chunked (typically 500-1000 tokens with overlap), embedded using an embedding model (OpenAI, Cohere, or open-source), and stored in PostgreSQL with pgvector indexes.
Hybrid search combines vector similarity (semantic) with keyword search (BM25) for better retrieval quality. PostgreSQL's full-text search handles the keyword component; pgvector handles the semantic component. Results are combined using reciprocal rank fusion.
Row-Level Security enforces tenant isolation at the database level — each tenant's vectors are only searchable by authorized users. This eliminates a common RAG vulnerability where cross-tenant data leakage is possible.
Query processing: user queries are embedded, similarity search runs against the vector index, results are re-ranked, and the most relevant chunks are passed to the LLM for answer generation with citations.
pgvector runs inside PostgreSQL — no additional service to manage, monitor, or pay for. Trade-off: pgvector may be slower than dedicated vector databases at extreme scale.
Combining semantic and keyword search catches cases where either alone fails. Trade-off: hybrid search adds query complexity and requires tuning the fusion algorithm.
Vector search automatically respects tenant boundaries. Trade-off: RLS policies must be designed and tested carefully — mistakes can leak data across tenants.
PostgreSQL has decades of tooling, monitoring, and operational knowledge. Trade-off: vector search is a newer capability — some edge cases are less documented than dedicated vector databases.
PostgreSQL with pgvector is significantly cheaper than dedicated vector databases. If you are already running PostgreSQL, pgvector adds zero infrastructure cost — just the extension. Supabase includes pgvector in all tiers. For a knowledge base with 100K documents, embedding costs are $5-20 one-time (depending on model), and vector storage adds approximately 20% to database size. No ongoing vector-specific infrastructure costs.
We use PostgreSQL with pgvector for all RAG systems unless the scale or feature requirements justify a dedicated vector database. Our strongest experience is building multi-tenant RAG where Row-Level Security ensures each tenant can only search their own documents.
We have built hybrid search systems combining pgvector's semantic search with PostgreSQL's full-text search for improved retrieval quality. The key insight: semantic search catches conceptual matches but misses exact terminology; keyword search catches exact matches but misses conceptual similarity. Combining both produces significantly better results.
Our RAG architecture includes document chunking strategies (recursive character splitting, semantic chunking), embedding model selection (OpenAI, Cohere, open-source), and retrieval evaluation pipelines. Every RAG system we deliver includes a retrieval quality benchmark against real queries.
Estimate architecture, cost, and ROI before you commit.
Deep-dives into architecture, cost, and implementation.
How we designed tenant isolation for a school operating system serving 50+ institutions.
When pgvector is enough and when you need a dedicated vector database.
Real projects, real architecture, real outcomes.
Tell us about your knowledge base. We will recommend the right architecture — whether that is pgvector, a dedicated vector database, or something simpler than RAG entirely.