System Design

15 Types of Databases and When to Use Each

The database landscape is bigger than 'SQL or NoSQL.' There are at least fifteen distinct kinds, each built for a particular shape of data and access pattern. This is the map - what each type is, and when to reach for it.

By Admin2026-06-1816 min readdatabasessystem-designsqlnosqldata-modelingarchitecture

Ask most engineers about database types and you'll hear "SQL or NoSQL." That's a useful first cut, but it badly undersells how varied the landscape actually is. Underneath those two umbrellas - and sometimes outside them - sit at least fifteen distinct kinds of database, each designed for a particular shape of data and a particular access pattern. Knowing them isn't trivia: in a system design interview, recognizing that a problem calls for a time-series database or a search engine rather than forcing it into a relational table is exactly the kind of judgment that signals depth.

This is the map. For each type: what it is, and when to reach for it.

graph TD
    DB[Databases] --> REL[Relational / SQL]
    DB --> NOSQL[Non-relational]
    DB --> SPEC[Specialized]
    NOSQL --> KV[Key-Value]
    NOSQL --> DOC[Document]
    NOSQL --> WC[Wide-Column]
    NOSQL --> GR[Graph]
    SPEC --> TS[Time-Series]
    SPEC --> SE[Search]
    SPEC --> VEC[Vector]
    SPEC --> OTHER[Spatial, Ledger,<br/>Columnar, more]

This diagram organizes the database landscape into three broad groups. Relational or SQL databases form one group. Non-relational databases form another, including key-value, document, wide-column, and graph databases. Specialized databases form a third group, including time-series, search, vector, spatial, ledger, and columnar databases, among others. The fifteen types in this guide span all three groups.

1. Relational (SQL) databases

What it is. The classic database: data in tables of rows and columns, with a fixed schema and relationships between tables, queried with SQL. Provides ACID transactions and powerful querying across related data.

When to use it. When your data is structured and relational, you need complex queries and joins, and correctness matters (transactions). This is the sensible default for a huge range of applications - anything transactional like e-commerce, finance, or core business data. Reach for it first, and move away only when you have a specific reason.

2. Key-value stores

What it is. The simplest model: data is keys mapped to values, like a giant dictionary. Extremely fast lookups by key, scales horizontally with ease, but you can only access data by its key.

When to use it. When you need fast, simple lookups by a known key and don't need complex queries - caching, session storage, user preferences, simple high-throughput lookups. When the access pattern is purely "give me the value for this key," nothing is faster or simpler.

3. Document databases

What it is. Stores data as documents (typically JSON-like), each a self-contained record with a flexible, possibly nested structure. You can query within documents, and the schema can vary between records.

When to use it. When your data is naturally document-shaped and the schema varies or evolves - content management, product catalogs with varying attributes, user profiles with optional fields. Good when you want flexibility and your access pattern centers on whole documents rather than cross-record joins.

4. Wide-column stores

What it is. Organizes data into rows and columns but far more flexibly than relational tables, and is built for enormous scale and high write throughput across many machines. Queries are typically by key, with some flexibility in the columns.

When to use it. When you have massive volumes of data and very high write rates that exceed what a relational database handles well - large-scale event data, time-stamped records, systems writing enormous streams. Built for horizontal scale where the access pattern fits its model.

5. Graph databases

What it is. Stores entities and the relationships between them as first-class citizens, optimized for traversing those relationships. Queries that follow connections (friends of friends, shortest paths) are fast and natural.

When to use it. When relationships are the point and you frequently query across them - social networks, recommendation engines, fraud detection (following chains of connections), knowledge graphs. Use it when the queries you care about are about how things connect, which would require painful joins in a relational database.

6. Time-series databases

What it is. Specialized for data points indexed by time - optimized for writing and querying timestamped data, with efficient storage and time-based queries (aggregations over windows, recent data).

When to use it. When your data is fundamentally a stream of measurements over time - metrics and monitoring, IoT sensor data, financial tick data, application telemetry. When most queries are "what happened over this time window," a time-series database does it far better than a general one.

7. Search engines (full-text search)

What it is. Databases built for searching text - indexing documents so you can find them by their content, with relevance ranking, fuzzy matching, and fast text queries. Powered by inverted indexes.

When to use it. When you need rich text search over content - product search, document search, log search, any "search box" feature. Typically used alongside a primary database: the primary stores the data, the search engine indexes it for fast, relevance-ranked text queries.

8. In-memory databases

What it is. Keeps data in RAM rather than on disk, trading durability and capacity for blazing speed. Often used as caches or for data that benefits enormously from sub-millisecond access.

When to use it. When speed is paramount and the data is hot and bounded - caching, real-time leaderboards, rate limiting, session data. Used as a fast layer in front of a slower primary store, or for transient data where losing it on a restart is acceptable.

9. Columnar (analytical / OLAP) databases

What it is. Stores data by column rather than by row, which makes analytical queries that scan many rows but few columns extremely efficient. Built for analytics (OLAP), not for transactional workloads (OLTP).

When to use it. When you're doing analytics over large datasets - aggregations, reporting, data warehousing, business intelligence. When queries scan millions of rows to compute sums and averages over a few columns, columnar storage is dramatically faster than row-based. Used for the analytics side, separate from the transactional database.

10. Object storage

What it is. Stores large unstructured objects (files, images, videos, backups) as blobs, accessed by a key, at massive scale and low cost. Not a database for querying structured data - a store for big files.

When to use it. When you need to store large files or unstructured data cheaply and durably at scale - images, videos, documents, backups, data lakes. Typically paired with a database that stores metadata and pointers to the objects.

11. Vector databases

What it is. Stores high-dimensional vectors (numerical representations of data, often from machine learning models) and finds the most similar vectors efficiently. Built for similarity search rather than exact-match queries.

When to use it. When you need similarity search - semantic search, recommendation by similarity, and retrieval for AI applications (finding relevant content by meaning rather than keywords). A newer category that's become important with the rise of embedding-based AI systems.

12. NewSQL databases

What it is. Databases that aim to provide the scalability of NoSQL while keeping the relational model and ACID transactions - distributed SQL databases that scale horizontally without giving up strong consistency and SQL.

When to use it. When you need both relational guarantees (ACID, SQL, transactions) and horizontal scale beyond a single machine - large-scale systems that can't relax consistency but have outgrown a single relational server. The category that tries to avoid the classic SQL-versus-scale trade-off.

13. Ledger / immutable databases

What it is. Maintains an immutable, append-only, cryptographically verifiable record of all changes - you can't alter history, only append, and the integrity of the record can be verified.

When to use it. When you need a tamper-evident, auditable history - financial ledgers, audit trails, supply-chain records, anywhere proving the integrity and history of data matters. Use it when immutability and verifiability are the requirement.

14. Spatial / geospatial databases

What it is. Optimized for storing and querying geographic and spatial data - locations, shapes, regions - with efficient spatial queries (what's near this point, what's within this area) powered by spatial indexes.

When to use it. When location is central - mapping, ride-sharing, delivery, "find restaurants near me," geofencing. When your queries are fundamentally about space and proximity, a spatial database (or spatial extensions to a relational one) handles them far better than naive distance calculations.

15. Embedded databases

What it is. A database that runs inside an application as a library rather than as a separate server - lightweight, with no separate process to manage, storing data locally.

When to use it. When you need local data storage without the overhead of a database server - mobile apps, desktop applications, edge devices, local caches, browser storage. When the data is local to one application instance and a full database server would be overkill.

The most important split: OLTP vs OLAP

Before choosing among the fifteen, there's one distinction that organizes much of the landscape: transactional (OLTP) versus analytical (OLAP) workloads.

OLTP (Online Transaction Processing) is the world of many small, fast operations - reading and writing individual records, the bread and butter of an application serving users. Place an order, update a profile, fetch a record. Relational databases, key-value stores, and document databases are typically OLTP systems: fast on individual records, transactional, serving the live application.

OLAP (Online Analytical Processing) is the world of large analytical queries - scanning millions of records to compute aggregates, for reporting and business intelligence. "Total revenue by region by month for the last three years." Columnar databases and data warehouses are OLAP systems: built to scan huge volumes efficiently, not to serve fast individual-record operations.

This split matters because the same data often needs both: an OLTP database serves the live application, and the data is also copied into an OLAP system for analytics. Trying to run heavy analytical queries directly on your transactional database is a classic mistake - it bogs down the database serving your users. Recognizing whether a need is transactional or analytical, and using the right kind of system for each, is one of the most consequential data-architecture decisions there is. Several of the fifteen types fall cleanly on one side or the other of this line.

How real systems combine types

The most important thing to internalize is that real systems rarely use just one database type - they combine several, each handling what it's best at. Consider a large social platform. Its architecture might use:

• A relational database for core transactional data (accounts, relationships) where consistency matters.
• A key-value or in-memory store as a cache for hot data and sessions, for speed.
• A wide-column store for the massive volume of activity events (posts, likes) at high write rates.
• A graph database for the social graph and friend-recommendation queries.
• A search engine for searching posts and users by text.
• Object storage for photos and videos.
• A columnar/OLAP system for analytics on user behavior.
• A time-series database for operational metrics and monitoring.

That's eight database types in one system, each chosen because it fits a specific need. This is polyglot persistence - using multiple database types together rather than forcing everything into one. The art isn't picking the database; it's recognizing the distinct data needs within a system and matching each to the type that serves it best. A single database forced to do all of this would do most of it poorly.

The relational default, and when to leave it

A practical principle that cuts through the abundance of choice: start with a relational database, and move to a specialized type only when you have a specific reason. Relational databases are versatile, well-understood, transactional, and handle a remarkable range of needs, especially with caching and replication. The fifteen types exist because specific needs genuinely outgrow what relational handles well - but most needs don't.

So the decision pattern is: default to relational for your core data; add a cache (in-memory or key-value) early because speed almost always matters; and reach for a specialized type (time-series, search, graph, columnar, vector, object storage) when you hit a specific need it serves and relational doesn't. This keeps you from the twin mistakes of forcing everything into one database (serving some needs poorly) and prematurely adopting exotic databases for needs you don't yet have (drowning in complexity). Match the specialization to the actual, demonstrated need.

The types at a glance

Interview: You won't be asked to recite all fifteen, but recognizing which type a problem calls for is a strong signal. When a design involves metrics over time, naming a time-series database; when it involves search, naming a search engine; when it involves relationships, naming a graph database - that shows you see beyond "SQL or NoSQL." The most senior move is recognizing that real systems use several types together: a relational database for core data, a cache for speed, a search engine for search, object storage for files. Picking the right tool per need - rather than forcing everything into one database - is exactly the judgment interviewers reward.

The bottom line

The database landscape is far richer than "SQL or NoSQL." Fifteen distinct types each serve a particular shape of data and access pattern: relational for structured transactional data; key-value, document, wide-column, and graph for the major non-relational needs; and a spectrum of specialized stores - time-series, search, in-memory, columnar, object storage, vector, NewSQL, ledger, spatial, and embedded - each built for a specific job. The skill isn't memorizing them; it's recognizing which type a problem's data and queries call for, and knowing that real systems combine several.

Match the type to the need, and combine them where each fits, and you're reasoning about data the way strong system designers do. We cover database selection across System Design Fundamentals.

Go deeper

• Database (Wikipedia) - the broad taxonomy of database types.
• The System Design Primer - database types among the system design building blocks.
• Designing Data-Intensive Applications - the definitive reasoning about data models and storage.
• AWS Databases - a practical catalog of database types and their uses.

More articles