What is the difference between SQL and NoSQL databases?

SQL (relational) databases store structured rows with a fixed schema and use joins and ACID transactions. NoSQL is an umbrella for non-relational models — document, key-value, wide-column and graph — that trade some consistency or schema rigidity for flexibility and horizontal scale.

When should I use a document database?

Choose a document store like MongoDB when records vary in shape, data is naturally nested, and the schema evolves often. It avoids many joins by embedding related data, which suits catalogues, content management and user profiles.

What is a vector database for?

Vector databases index high-dimensional embedding vectors and answer approximate-nearest-neighbour queries. They power semantic search, retrieval-augmented generation (RAG) and recommendations by finding the items whose embeddings are closest to a query vector.

What is a wide-column database?

Wide-column stores such as Cassandra organise data into rows with dynamic columns grouped in column families, partitioned across many nodes. They excel at write-heavy, high-availability workloads that need linear horizontal scaling, like event logging and time-keyed data.

Can I use more than one database type?

Yes — this is called polyglot persistence and is very common. A typical stack might pair a relational system of record with Redis for caching, Elasticsearch for search and a vector store for AI features, each handling the access pattern it is best at.

Database Type Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Choosing the right database model

Databases are not interchangeable: each category is optimised for a particular data model and access pattern. This reference compares the main types — relational, document, key-value, wide-column, graph, time-series, search, vector, columnar/OLAP and ledger — with the data model, typical query interface, example systems and the workloads each fits best.

How it works

The right choice follows from your dominant query shape and your consistency and scale requirements, not from popularity. A rough decision map:

Joins + transactions + strong consistency   → Relational
Nested, varying records, flexible schema     → Document
Fast lookup by known key, caching/sessions   → Key-Value
Write-heavy, linear horizontal scale         → Wide-Column
Deeply connected relationships               → Graph
Timestamped metrics and events               → Time-Series
Full-text search and relevance ranking       → Search Engine
Semantic similarity / embeddings for AI      → Vector
Large-scale analytical aggregations          → Columnar / OLAP
Tamper-evident audit history                 → Ledger / Immutable

The filter searches across type, model, examples and use case so you can find the category that matches the problem in front of you.

Tips and notes

Start from the dominant access pattern, then check consistency and scale needs.
Polyglot persistence is normal — most production systems combine several types.
Many relational engines now support JSON, vectors (pgvector) and time-series too.
Match the data model to the problem, not the other way around.