Types of Databases: A Map for Builders
"Just use Postgres" is good advice until a measured access pattern needs a specialist. A checkout might use Redis for the cart, SQL for order and inventory, a vector index for recommendations, and a warehouse for later analytics.
For developers reading architecture diagrams or choosing storage for a feature, this guide separates core storage and access models from specialty domain requirements. You will be able to label each store by the question it answers and avoid comparing categories that sit on different axes. Product examples and category labels are current as of July 2026; verify current vendor capabilities before selecting a store. When you need a decision worksheet, continue with How to Choose the Right Database; for AI retrieval stores see Vector Database Map.
Map storage models and specialty overlays
Group first, but name the axis. Storage and access models include relational, document, key-value, columnar, time-series, graph, spatial, and object-oriented. Deployment or execution properties include distributed SQL and memory-first operation. Domain overlays include vector similarity for AI retrieval and append-only or tamper-evident ledger semantics for audit workflows.
These labels overlap because they answer different questions: PostgreSQL can be relational, memory-cached, spatial through PostGIS, time-series through Timescale, and vector-capable through pgvector. A specialty engine earns a separate cluster only when a measured query, scale, trust, or operating requirement exceeds that combined system.
Quick reference
- Ask: shape of data, query pattern, consistency needs, and ops cost — in that order.
- Most products are polyglot: 2–4 stores, not twelve.
- Managed cloud versions change ops more than the data model.
- Wrong type usually fails as painful queries or expensive workarounds, not as a crash on day one.
Remember this
Wrong type usually fails as painful queries or expensive workarounds, not a crash on day one — PostgreSQL alone can be relational, spatial, time-series, and vector-capable before a specialty engine earns its own cluster.
SQL and NewSQL: transactions you can trust
SQL (relational) databases store structured rows in tables, speak SQL, and aim for ACID correctness. They remain the default for money, identities, orders, and anything that needs joins and strong consistency. Examples: MySQL, Microsoft SQL Server (and PostgreSQL in most greenfield apps).
NewSQL keeps SQL + ACID while targeting horizontal scale for large transactional apps. Examples: CockroachDB, Google Spanner. Use NewSQL when you have outgrown a single primary and need distributed SQL — not because the word "New" sounds modern.
Quick reference
- SQL — structured data, ACID, relational model; MySQL, SQL Server, PostgreSQL.
- NewSQL — NoSQL-like scale with SQL guarantees; CockroachDB, Spanner.
- Start relational unless you have a measured reason not to.
- Schema migrations and indexes are part of the job — budget for them.
Remember this
NewSQL earns its place once a single primary has actually been outgrown and transactions must shard — not because the word "New" sounds like the modern default.
Document, key-value, and in-memory stores
Document databases store JSON/BSON with flexible schemas — natural for web apps and evolving product data. Examples: MongoDB, Couchbase.
Key-value databases map keys to values for fast lookups — ideal for caching, sessions, and real-time counters. Examples: Redis, Amazon DynamoDB (also a flexible NoSQL workhorse).
In-memory databases keep the working set primarily in RAM for ultra-low latency. Examples: SAP HANA, SingleStore (formerly MemSQL). Use when milliseconds matter and you can afford memory — not as a substitute for durable system-of-record without a persistence story.
Quick reference
- Document — flexible schemas, JSON/BSON; MongoDB, Couchbase.
- Key-value — simple pairs, fast lookups; Redis, DynamoDB.
- In-memory — RAM-first speed; SAP HANA, SingleStore.
- Redis often sits in front of SQL as cache — not instead of it.
Remember this
Redis sits in front of SQL as a cache, not instead of it — an in-memory store is the wrong choice the moment durable system-of-record behavior is needed without a persistence story.
Columnar and time-series: analytics shapes
Columnar databases store data by column, which speeds read-heavy analytics and aggregations (scan only the columns you need). Examples in the wild: Amazon Redshift for warehouses; Cassandra is often grouped here in marketing slides but is really a wide-column store for high-write, partition-keyed workloads — know the difference when you design.
Time-series databases optimize timestamped measurements for IoT, monitoring, and finance. Examples: InfluxDB, TimescaleDB (Postgres extension). Prefer them when time ranges and downsampling dominate every query.
Quick reference
- Columnar / analytics — Redshift, BigQuery, Snowflake; wide-column cousins like Cassandra for write-heavy partitions.
- Time-series — InfluxDB, TimescaleDB for IoT and metrics.
- Do not put your OLTP checkout cart in a warehouse engine.
- Retention policies and continuous aggregates matter as much as ingest rate.
Remember this
A large sequential scan for a revenue report competing with live checkout traffic is the symptom of an analytics query run against the OLTP table — a derived columnar copy scans only the report columns and leaves checkout alone.
Graph and spatial: relationships and place
Graph databases make relationships first-class — perfect for social graphs, recommendations, and fraud rings. Examples: Neo4j, Azure Cosmos DB (Gremlin/API for graph among other models).
Spatial databases store geographic and location data for GIS, maps, and urban planning. Examples: PostGIS (PostgreSQL), Oracle Spatial. If your queries are "within radius" and "intersects polygon," you want spatial indexes — not a JSON blob of lat/long with table scans.
Quick reference
- Graph — Neo4j, Cosmos DB graph APIs for relationship-heavy domains.
- Spatial — PostGIS, Oracle Spatial for GIS and mapping.
- Many fraud and recommendation systems combine graph + relational.
- PostGIS is often enough without a separate spatial product.
Remember this
"Within radius" and "intersects polygon" queries want spatial indexes, not a JSON blob of lat/long forcing a table scan — PostGIS covers most of that need before a separate spatial product is justified.
Specialty overlays use a different axis
This section deliberately changes axes. An object-oriented database is primarily a storage model: it persists language-shaped objects and identity. Vector describes an index and access pattern—nearest-neighbor search over embeddings—which can live in a dedicated engine such as Milvus or Pinecone or inside PostgreSQL and search platforms. Ledger describes write and trust semantics such as append-only history, cryptographic verification, or multi-party agreement; it does not prescribe one query model.
Do not ask which of these three is the universal “database type.” Ask separate questions: must application objects be persisted directly, must queries retrieve semantic neighbors, or must history be tamper-evident across a stated trust boundary? Those requirements can coexist with SQL, document, graph, or key-value storage rather than replace them.
Quick reference
- Storage-model axis: object-oriented — db4o, ObjectDB; rare in greenfield web stacks.
- Access-pattern axis: vector — Milvus, Pinecone, or extensions for similarity search.
- Trust/write-semantics axis: ledger systems for append-only or verifiable history.
- pgvector and Neo4j vector indexes blur lines — start simple when possible.
- A product may occupy several axes; label the capability you actually need.
Remember this
There's no universal "database type" among object-oriented, vector, and ledger — they answer three separate questions (persist objects directly? retrieve semantic neighbors? need tamper-evident history?) that can each coexist with SQL, document, or graph storage.
Choose with a short checklist
Walk the checklist: (1) Need ACID + joins? SQL (or NewSQL if you must shard transactions). (2) Evolving JSON documents? Document. (3) Cache / sessions / hot keys? Key-value or in-memory. (4) Aggregations over huge fact tables? Columnar. (5) Metrics over time? Time-series. (6) Deep relationship queries? Graph. (7) Maps and GIS? Spatial. (8) Embeddings / RAG? Vector. (9) Multi-party immutable audit? Ledger/blockchain. (10) Pure object persistence without ORM? Only if you truly need an OODB.
Practice: take one product feature and list the primary type plus one optional specialty store. If you need more than three, simplify the design before you simplify the vendor list.
Quick reference
- Default stack for many SaaS apps: PostgreSQL + Redis (+ optional vector).
- Add specialty stores only after a measured pain (latency, query shape, scale).
- Prefer extensions (PostGIS, Timescale, pgvector) before new clusters.
- Document the why in your architecture decision record.
Remember this
If a feature needs more than three stores to justify, simplify the design before simplifying the vendor list — PostgreSQL plus Redis already covers most SaaS defaults without a fourth specialty engine.
Zoom into one checkout feature
Trace a single checkout: Redis holds the cart (key-value / in-memory), SQL commits the order and inventory (ACID), optional vector search ranks "you might also like," and a columnar warehouse gets the event for analytics later. That is polyglot persistence on purpose — not twelve databases on day one.
When to add a specialty store: measured pain (latency, query shape, scale). When not to: Postgres + Redis already covers the feature and you have not measured a bottleneck.
Quick reference
- Cart / session → key-value or in-memory.
- Money / inventory → SQL transaction.
- Recommendations → vector (or SQL until volume hurts).
- Dashboards → columnar / warehouse, often async.
- Practice: label each store in an app you know by type, not by brand.
Remember this
Redis for the cart, SQL for the order, and a warehouse for analytics later is polyglot persistence on purpose — a specialty store earns its slot only after a measured bottleneck, not on day one.
Key takeaway
The map above separates storage models (SQL, document, key-value, graph, columnar, time-series, NewSQL, in-memory) from specialty overlays (vector, spatial, object, ledger). They are lenses on access patterns, not twelve peer shopping-list peers. Most teams need a relational core plus one or two specialists.
Practice (20 min): Inventory the stores in one system and, for each, write the access pattern, consistency need, ownership boundary, and whether it is a core model or specialty overlay. The expected result is one requirement-backed reason for every store. Intentionally remove one specialist or tighten one consistency requirement; recover by moving the workload to the relational core or documenting why the specialist must remain. Pass when every store has a measurable requirement, a failure fallback, and no choice is justified only by a product name.
Related Articles
Explore this topic