Relational, NoSQL, vector or graph: which to use?

Relational, document, key-value 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 than in a relational engine, 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 the real question is "who is connected to whom" rather than "how many are there". Knowing the differences helps you choose deliberately, rather than follow whatever is trending that quarter, before ending up maintaining more systems than the problem required.

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, not by a technology trend.

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. The practical criterion stays the same either way: start from the problem you need to solve, not from the most talked-about database family that quarter, and add complexity only when the default stops holding up.