Databases / Compare
Compare database types.
Database models and deployment choices, different jobs. Compare the data model, typical workload, and costs of each before narrowing the choice to a product.
Compare products as well as models.
SQL Server, Oracle Database, PostgreSQL, and MySQL are engines. Cloud SQL, RDS, Azure SQL, and Autonomous Database are managed offerings with different boundaries. Use the provider pages to compare named products, then use the family table to understand the data model.
Search the full database directory →Comparison / 02
Know the families before the brands.
Categories overlap. Time-series tools can be relational; a document database may support transactions. Evaluate the exact product, version, and deployment.
| Family | Typical workload | Model & examples | When to choose | Watch out for |
|---|---|---|---|---|
| Relational | Orders, accounts, inventory | Rows, relationships, constraintsPostgreSQL, MySQL, SQL Server, Oracle Database, Db2, SQLite | Start here for related records and transactional rules. | Indexes add write cost; isolation and deployment still need deliberate choices. |
| Document | Content, catalogs, variable records | Documents with nested fieldsMongoDB, Firestore, Cosmos DB, DocumentDB, Couchbase | Choose when each document matches a common read or write boundary. | Cross-document rules, validation, and duplicated data need a plan. |
| Key-value | Known-key lookups and caches | Keys and valuesDynamoDB, Cosmos DB, Oracle NoSQL, Redis, Valkey | Choose for predictable key access; distinguish primary records from caches. | Durability, eviction, query options, and consistency vary by product and configuration. |
| Columnar | Event analysis and reporting | Columns optimized for scansBigQuery, Redshift, Snowflake, Fabric Warehouse, ClickHouse, DuckDB | Choose for aggregating many rows and reading a subset of columns. | Frequent transactional updates and point lookups may belong in another store. |
| Wide-column | Large partitioned datasets, telemetry | Rows organized by partition and row keysBigtable, Apache Cassandra | Choose for known partition-key queries and sustained distributed ingestion. | This is distinct from columnar analytics; joins, cross-partition transactions, and hotspot behavior need attention. |
| Distributed SQL | Relational workloads with distributed writes | Coordinated transactions across partitions or regionsSpanner, CockroachDB, Aurora DSQL | Choose when one primary cannot meet measured write-placement or scale requirements. | Check SQL compatibility, transaction retries, locality, supported region sets, and coordination latency. |
| Time series | Metrics, telemetry, sensor history | Timestamped events and time windowsTimescaleDB, InfluxDB | Choose when time-window queries, retention, and continuous ingestion dominate. | Plan late arrivals, cardinality, retention, and partition size. |
| Search | Text discovery and relevance | Search indexesElasticsearch, Azure AI Search, OpenSearch, Typesense | Choose for ranked retrieval, language analysis, and filtering. | Keep a source of truth and a tested reindexing path; results may lag writes. |
| Graph | Fraud paths, networks, dependencies | Nodes and relationshipsNeo4j, Amazon Neptune | Choose when multi-hop relationships are the core query pattern. | Test realistic traversals; a relationship diagram alone does not justify another store. |
Examples are reference points, not rankings. Check current capabilities, licenses, pricing, and regional availability. Documentation & editorial method →
Read the comparison in context
The query pattern is the useful dividing line.
Related records and changes that span several entities often make a relational model a useful first candidate. A document model is worth testing when a document matches the information the application typically reads and updates together. Known-key access points toward a key-value design; ranked text retrieval has a different job again.
For analytical work, the question is often how efficiently the system scans and aggregates a large set of values. For graph work, it may be whether the central queries repeatedly traverse relationships. Test the actual query rather than choosing a model because its diagram resembles your domain.
These categories overlap. A relational database can store flexible attributes, and a specialized database can support more than one model. Capabilities, correctness guarantees, and operating costs depend on the exact product and configuration.