Why there are so many types of databases
Published on 2026-09-12 by frfrand
No es moda: cada familia optimiza algo distinto y paga por ello en otro lado. Relacionales, documentos, clave-valor, columnares, grafos y series temporales, con el caso donde cada una gana.
Twenty years ago the answer was a single one: relational database. Today there are dozens of options and the choice generates entire discussions.
The reason is not fashion. It is that each database family optimizes something different, and pays for it elsewhere. Knowing the trade-off of each one turns the discussion into a decision.
Relational
Data in tables with explicit relationships. Postgres, MySQL, SQLite.
Optimize: integrity and complex queries. You can ask "all customers who bought more than three times last month and did not return" in a single query, and trust the result.
Pay: the schema is rigid. Changing it requires a planned migration.
Document
They store complete objects, like JSON. MongoDB, CouchDB.
Optimize: flexibility of shape. Each record can have different fields, and there is no migration to add one.
Pay: relationships become your problem. Without real joins, you end up doing several queries and joining in the application, or duplicating data and keeping it synchronized manually.
An honest note: many people chose documents for flexibility and ended up implementing by hand what a relational database already did. And today Postgres stores indexable JSON, which erased much of the advantage.
Key-value
One key, one value, direct access. Redis, Memcached.
Optimize: speed. Reads and writes in microseconds, because they live in memory.
Pay: there are no queries. You can only search by exact key. And if it's just memory, a restart wipes everything (Redis can persist, but that's not its strong suit).
It's almost always used next to another database, not instead of it: cache, sessions, queues, counters, rate limits.
Columnar
They store by column instead of by row. ClickHouse, BigQuery.
Optimize: aggregations over millions of rows. "Average sales by region over the last three years" on a billion records, in seconds, because they only read the columns they need.
Pay: they're bad for transactional work. Fetching a full row or updating a record is expensive.
Graph
Nodes and relationships as first-class citizens. Neo4j.
Optimize: relationship questions across multiple hops. "Friends of friends who worked at the same company" is natural here and horrible in SQL.
Pay: everything else. They're specialized.
Time series and search
Time series (InfluxDB, TimescaleDB): time-ordered measurements, compressed, with automatic deletion of old data. Metrics and sensors.
Search (Elasticsearch, OpenSearch): text with relevance, typo tolerance, language analysis. A SQL LIKE doesn't come close.
The honest default
For most projects: start with a relational database. It handles many more data formats than its reputation suggests, and solves integrity and complex queries that are later very expensive to reimplement.
Add a second one only when a measured limit appears. And keep in mind the real cost: two databases are two backups, two restores to test, and a consistency problem between both that is now yours.
The most common and healthiest pattern is: one relational database that holds the truth, and Redis ahead for what is read a lot.
