Relational, NoSQL, vector or graph: which to use?
Four database families born for different problems: transactions, scale, semantic search, relationships. They are not interchangeable.
Relational, NoSQL, vector and graph databases are four families born to solve different problems, not four competitors on the same ground. Relational databases (PostgreSQL, MySQL, SQL Server) organize data in tables with a rigid schema and guarantee consistent transactions: the default choice for anything touching money, orders, inventory, where losing a row or duplicating another is an incident. NoSQL, in document form (MongoDB) or key-value form (Redis, DynamoDB), shifts the balance toward horizontal scale and flexible schemas: ACID transactions are now nearly universal (MongoDB has supported multi-document transactions since 4.0, DynamoDB since 2018), but they stay more expensive and narrower in scope, and a flexible schema moves consistency constraints out of the database and into application code. Vector databases index embeddings and answer semantic similarity queries, the engine behind RAG and semantic search. Graph databases model nodes and explicit relationships, ideal when queries ask "who is connected to whom" rather than "how many are there".
See also: Vector database · A database that indexes data by meaning, not exact words: the memory RAG searches for content similar to a question.
The honest default
Many companies start convinced they need three or four specialized databases and end up discovering that PostgreSQL, with the pgvector extension, covers more ground than it seems: solid transactions, JSON for semi-structured data, and vector search in the same engine, without syncing separate systems. It is not always the right choice, but it is the one to rule out last: adding a specialized database has a real operational cost, another system to monitor, back up, secure, and it needs to be justified by a problem the default does not solve.
When a specialized database is truly needed
A dedicated graph database (Neo4j and similar) makes sense when queries traverse many relationship hops, typical of fraud detection or complex enterprise knowledge graphs. A dedicated vector database (Pinecone, Weaviate, Milvus) makes sense at very high embedding volumes or extreme latency requirements pgvector no longer covers comfortably. In both cases the dedicated engine gets added when the default stops handling those hops, those volumes or that latency, not because its family is the most talked-about one that quarter.
Related terms
- Vector database · A database that indexes data by meaning, not exact words: the memory RAG searches for content similar to a question.
- Knowledge graph · A network representing company data as entities and relationships: customers, products, contracts and the links connecting them.
- Normalization vs denormalization · Normalizing reduces redundancy for integrity, denormalizing reintroduces it for faster reads: two opposite goals, both legitimate.
- MongoDB vs DynamoDB · Two NoSQL databases competing for the same decision: software portability or managed integration inside AWS.
- Multi-model database · A database handling multiple data models in one product, often without unifying their transactional guarantees.
If it touches your company's data, getting that data in order is the first thing I do.
SEE DATA FOUNDATIONS