Many companies do not need a separate vector database at the beginning. They first need clean data, strong metadata and a controlled retrieval process. pgvector brings vector search into PostgreSQL, keeping embeddings, relational data and permissions in the same system for many practical MVP and SMB scenarios.
Why does the wrong architecture often start with the wrong question?
When companies start planning a Company Brain, the technical discussion quickly turns into a vector database discussion. Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch with vector search, OpenSearch, pgvector. The list becomes long very quickly. But the real question is usually not: “Which vector database is the best?” It is: “Are our documents and knowledge objects prepared well enough for retrieval to be reliable?”
A Company Brain usually does not fail because the vector search engine is not advanced enough. It fails because documents exist twice, metadata is missing, versions are unclear, permissions are loosely defined and nobody can say which source is currently approved.
That is exactly why pgvector is attractive. The extension brings vector search directly into PostgreSQL. Embeddings can live next to customers, roles, processes, document metadata, status models, audit logs and tasks. pgvector supports exact and approximate nearest neighbor search, multiple vector types and distance metrics such as L2 distance, inner product, cosine distance, L1, Hamming and Jaccard.
Why does pgvector fit a Company Brain so well?
A Company Brain is not just a search engine. It is a controlled knowledge system. It should not only find semantically similar text passages. It should also check whether those passages are valid, approved, owned, customer-specific and visible to the current user.
This is the practical advantage of PostgreSQL with pgvector. The embedding is not isolated next to the application. It can be connected to classic tables. A query does not have to mean only: “Find similar chunks.” It can mean: “Find similar chunks, but only from approved knowledge objects, for this tenant, this role, this process and this current version.”
That may sound less dramatic than a pure vector architecture. In real operations, it is often more important. Small and mid-sized businesses do not usually need maximum specialized infrastructure on day one. They need a system that will not become chaotic after three months.
When is PostgreSQL with pgvector enough?
PostgreSQL with pgvector is often enough when the Company Brain is used for internal knowledge search, assistant features, document retrieval, FAQ systems, proposal preparation, process knowledge or customer service support. These scenarios usually have manageable data volumes, moderate query load and a strong need for metadata filtering.
For example, a mid-sized company may want to search internal work instructions, project knowledge, proposal modules, technical documentation and field experience. Users expect useful answers, but they do not need billion-vector search at millisecond latency. What matters more is that the assistant does not use an archived checklist, does not select the wrong customer version and does not expose documents from another tenant.
For this kind of problem, pgvector is often strong enough. PostgreSQL remains the leading system for context, relationships and governance. pgvector adds semantic search inside that structure.
When does a separate vector database make more sense?
A separate vector database becomes more interesting when vector search itself becomes the central scaling problem. This can happen with very large datasets, very high query volume, very low latency requirements, complex multi-embedding architectures, specialized indexing strategies or teams that operate retrieval infrastructure as a dedicated service.
Separation can also make sense organizationally. Crunchy Data, for example, recommends physically separating application data and vector data in scaling scenarios, while still allowing PostgreSQL-based systems to connect them through the Postgres foreign data wrapper.
This is not a contradiction. For an MVP or an SMB system, pgvector can be the right first choice. For a large platform with heavy vector workloads, separation or a specialized database may become reasonable later. The decision should come from real requirements, not from architectural fashion.
How does pgvector compare with a dedicated vector database?
| Criterion | pgvector in PostgreSQL | Dedicated vector database |
|---|---|---|
| Data storage | Embeddings, metadata and relational data remain in one system | Vectors often live separately from business objects |
| Governance | Roles, tenants, versions and approvals can be filtered directly in SQL | Metadata filters are possible, but synchronization is often required |
| Operations | Fewer systems and simpler MVP operations | Additional infrastructure, monitoring and data pipelines |
| Scaling | Strong fit for many SMB and internal RAG scenarios | Better fit for very large vector collections and heavy query load |
| Risk | Lower integration complexity | More architectural decisions, but more specialization |
The key point is simple: pgvector is not automatically better. A dedicated vector database is not automatically more professional. The right choice depends on whether the real bottleneck is governance, data quality and context or large-scale vector search performance.
Which indexes and distance metrics does pgvector support?
pgvector supports exact search and approximate nearest neighbor search. For indexes, it supports HNSW and IVFFlat. Supabase explains that pgvector currently supports HNSW and IVFFlat, and generally recommends HNSW because of its performance and robustness with changing data.
HNSW builds a graph structure. It usually requires more memory and slower build times than IVFFlat, but often provides a better speed-recall tradeoff. IVFFlat is list-based and can work well with the right data and tuning.
For a Company Brain, the index type is only part of the story. The retrieval pipeline matters just as much. An uncontrolled semantic match can be mathematically similar but operationally wrong. Retrieval should therefore always be combined with metadata, versions, permissions and source checks.
Which numbers help put pgvector into context?
pgvector is not a small experiment. The project has more than 21,000 stars on GitHub and is described as open-source vector similarity search for PostgreSQL.
For HNSW indexes, Supabase states that in pgvector 0.7.0 and above, indexed dimensions can go up to 2,000 for vector, 4,000 for halfvec and 64,000 for bit.
PostgreSQL itself remains broadly adopted as a database environment. In the 2025 Stack Overflow Developer Survey, 55.6 percent of all respondents and 58.2 percent of professional developers reported extensive work with PostgreSQL in the previous year.
PostgreSQL 18 also shows ongoing development of the core platform. The PostgreSQL Global Development Group states that its new I/O subsystem demonstrated up to 3x performance improvements when reading from storage. This is not a direct pgvector benchmark, but it is relevant context for PostgreSQL as a long-term foundation.
Why is metadata more important than the vector itself?
An embedding is only a mathematical representation. It does not know whether a document is outdated. It does not know whether a user is allowed to see the information. It does not know whether a process draft has been approved. It also does not know whether a paragraph comes from an official source or an old note.
That is why a Company Brain should not be built from “text plus vector” alone. It needs at least document type, source, version, status, validity, owner, tenant, process relationship and permission logic. pgvector then becomes the semantic search mechanism inside a structured system.
Many companies want to start with AI and later discover that their data foundation is not reliable. The better order is different: first structure, then retrieval, then assistants, then automation.
What does a controlled retrieval process look like?
A controlled retrieval process does not start with similarity search. It starts with a question: Which content is even allowed to be a candidate? Only after that should vector search run.
In PostgreSQL, the flow could look like this: first, consider only approved, valid and user-visible knowledge objects. Then use pgvector to find semantically similar chunks. After that, check source, version and status. Only then generate an answer, ideally with source references and clear limits.
This does not eliminate every wrong answer. But it reduces a central risk: that an AI system answers confidently while relying on outdated, incorrect or unapproved knowledge.
What does this mean for an MVP?
For an MVP, pgvector is often the more reasonable choice. A company can start with PostgreSQL, capture documents in a structured way, model metadata, store embeddings and test the first retrieval functions. The architecture remains understandable. There are fewer moving parts. The data flow is easier to explain.
That matters when a Company Brain later becomes part of real workflows: proposal preparation, customer intake, internal FAQ, field documentation, privacy documentation or process assistance. In all of these cases, the question is not only whether a text is semantically similar. The question is whether the match is allowed to be used.
What should not be underestimated with pgvector?
pgvector makes vector search possible inside PostgreSQL, but it does not make it automatically good. Indexes need to be chosen and tested. Embedding models need to match the language and content. Chunking determines whether text passages can later be retrieved usefully. Filters can behave unexpectedly with approximate indexes; Supabase notes that naive filtering with IVFFlat or HNSW can return fewer rows than expected.
Backups, monitoring, memory consumption and query planning also remain real operational topics. Anyone treating pgvector as a plugin that can be installed and forgotten is underestimating the operational side.
What is the strategic recommendation for KrambergAI customers?
For many KrambergAI customers, the pragmatic path is: PostgreSQL first. pgvector when semantic search is actually needed. A separate vector database only when data volume, speed, scaling or organizational separation justify it.
That fits the principle of a Company Brain. Not every company needs specialized infrastructure immediately. But every company needs clean knowledge objects, clear sources, versions, permissions and traceable processes. That is where the real quality is created.
pgvector is therefore not just a technical extension. It is an architecture decision for lower complexity at the beginning. The strongest point remains this: many companies do not need a separate vector database at the start. They first need clean data, metadata and a controlled retrieval process.
Sources for the numbers used
- pgvector GitHub – more than 21,000 stars and open-source vector similarity search for PostgreSQL: https://github.com/pgvector/pgvector
- Supabase HNSW Indexes – maximum indexed dimensions in pgvector 0.7.0 and above: https://supabase.com/docs/guides/ai/vector-indexes/hnsw-indexes
- Stack Overflow Developer Survey 2025 – PostgreSQL usage among developers: https://survey.stackoverflow.co/2025/technology
- PostgreSQL 18 Release – up to 3x performance improvements for storage reads: https://www.postgresql.org/about/news/postgresql-18-released-3142/
Further reading
PostgreSQL Documentation – pgvector Extension Concepts in AlloyDB
https://docs.cloud.google.com/alloydb/docs/ai/run-vector-similarity-search
Supabase Docs – Vector Indexes
https://supabase.com/docs/guides/ai/vector-indexes
Crunchy Data Blog – Scaling Vector Data with Postgres
https://www.crunchydata.com/blog/scaling-vector-data-with-postgres
What is pgvector?
pgvector is an open-source PostgreSQL extension that adds vector data types and similarity search directly to Postgres. It allows embeddings to be stored and queried with SQL alongside relational data. For a Company Brain, this is useful because semantic matches can be connected directly to metadata, roles, sources and versions.
When is pgvector enough for a Company Brain?
pgvector is often enough when a company wants to build internal knowledge search, RAG, FAQ assistants or document retrieval with manageable data volume. It is especially useful when metadata, permissions, process context and versions matter more than extreme search speed across very large vector collections. For many MVPs, it is a practical starting point.
When should a company use a separate vector database?
A separate vector database becomes more useful when vector search itself is the main bottleneck. This includes very large datasets, high query frequency, low latency requirements or specialized retrieval teams. Clear technical separation can also be a reason. For an initial Company Brain, however, it is not automatically required.
Which distance metrics does pgvector support?
pgvector supports several distance metrics, including L2 distance, inner product, cosine distance, L1 distance, Hamming distance and Jaccard distance. The right metric depends on the embedding model and use case. For text retrieval, cosine distance is often used, but it should be validated with real content and queries.
Which index types are available in pgvector?
pgvector supports HNSW and IVFFlat for approximate nearest neighbor search. HNSW often provides a strong speed-recall tradeoff, but it usually needs more memory and slower build times. IVFFlat can work well for suitable data, but it requires careful configuration and training before it performs reliably.
Why is metadata so important in RAG systems?
RAG systems perform better when semantic search is combined with metadata. A match is not suitable just because it sounds similar. It must also be current, approved, visible to the user and relevant to the business context. Without metadata, an AI system may use outdated or unauthorized information.
Is pgvector easier for small and mid-sized companies to operate?
In many cases, yes. If PostgreSQL is already part of the stack, pgvector reduces the number of additional systems. Embeddings, metadata and business objects remain in one database. This simplifies operations, backup, permissions and MVP development. Indexes, memory, query performance and retrieval quality still need active monitoring.
Can a company move from pgvector to a vector database later?
Yes. A well-designed system can later be extended with a separate vector database. The important part is to model embeddings, chunk IDs, sources, versions and metadata cleanly from the start. Then vector search can be moved out while PostgreSQL remains the leading system for governance and business context.
