9 Types of Databases Explained

Almost every list of database types runs the same nine labels in a row: relational, NoSQL, document, key-value, wide-column, graph, object-oriented, hierarchical, operational. The labels are all in common use, but they do not answer the same question. Most name a data model, the structure the system stores records in. One, NoSQL, names an umbrella category that contains four of the others. One, operational, names a workload role, which describes what a database is used for rather than how it organizes data. Knowing which axis a label came from is what turns the list into something you can choose from.

This post walks through all nine: what each one stores, the access pattern it was built for, where its boundary sits, and which systems implement it. It also covers the two questions the list itself raises, namely how the umbrella relates to its families and why a workload role sits alongside data models, and closes with the types you will meet outside this list.

Why understanding database types matters

Choosing a database is mostly choosing a data model, and the data model is the hardest thing to change later. Storage engines get swapped, hardware gets resized, and query layers get rewritten, but the shape the data is stored in propagates into the schema, the application code, and every downstream consumer.

The access pattern selects the model. The same customer and order records can live in a relational schema, a document collection, or a graph, and all three will work. What differs is the cost of the question you ask most often. Fetching one order with all its line items favors a document; computing revenue by region across millions of orders favors columns and joins; finding every account that shares a device with a flagged account favors edges. The model to pick is the one that makes the frequent question cheap.

The wrong model rarely fails outright, which is the trap. A mismatch shows up as slow accretion: a query that needs three self-joins, then five, then a nightly job that pre-computes what the query could not do in time, then a cache to hide the job’s latency. Each step is individually reasonable, and by the time the pattern is obvious the workaround layer is load-bearing. Hard failures are easier to act on than this kind of gradual drag.

Switching later moves more than the data. A model change rewrites the schema, the query layer, the migration tooling, the monitoring, and the on-call runbook. It also touches every service that reads the old shape. That is why the choice deserves attention up front even when the initial dataset is small enough that any option would work.

Most systems past a certain size run several. Polyglot persistence, one store per data shape, is the normal end state: a relational system of record, a key-value cache, a document store for a catalog, a search index. The real question is usually not which single database to standardize on but which store owns which data and how they stay consistent.

Understanding the types, then, is less about picking a winner than about recognizing which shape a given workload wants and what it will cost to serve it with the store you already run. The rest of this post gives each type the same treatment: what it models, what it is good at, and where it stops.

9 types of database management systems

One clarification the terminology invites: a database is the organized collection of data, while a database management system (DBMS) is the software that stores, secures, and queries it. PostgreSQL is a DBMS; the tables you keep in it are a database. The two terms are used interchangeably in practice, including in this post, and the distinction only matters when the subject is the software rather than the data.

Reading down the axis column explains why this list feels uneven. Seven entries describe how records are structured. NoSQL describes a category defined by a break from the relational model rather than by a structure of its own, and the four families that follow it in the list sit inside it, so document, key-value, wide-column, and graph each appear once inside the umbrella and once on their own. Operational describes the job rather than the structure, which is why its example column repeats products from three earlier rows. A practical shortlist therefore proceeds in two steps: decide the workload role first, live traffic or analytics, then choose the data model inside it.

Three types you will meet that this list does not cover: vector databases, which index high-dimensional embeddings for similarity search and became standard infrastructure alongside retrieval-augmented generation; time-series databases such as InfluxDB and TimescaleDB, which specialize in append-heavy, timestamp-ordered measurements; and cloud databases, which name a deployment and operating model rather than a data model, since a cloud data warehouse or a managed Postgres instance still stores data in one of the shapes above.

Relational databases (SQL)

A relational database stores data in tables of rows and columns, enforces a schema defined ahead of time, and relates tables through keys. The model traces to Edgar Codd’s 1970 paper A Relational Model of Data for Large Shared Data Banks and is codified in the ISO/IEC 9075 SQL standard, which is why a query written for one engine is largely portable to another.

Three properties define the model in practice. The schema is enforced on write, so every row in a table has the same columns and types and malformed data is rejected at the door. Relationships are resolved at query time through joins rather than stored as physical links, so one normalized copy of each fact serves many different queries. And ACID transactions make a set of changes commit as a unit or not at all, which is what makes relational systems the default wherever concurrent correctness is non-negotiable: payments, inventory, ledgers, bookings.

Joins are what the model buys you. A question that spans three entities is one statement, and the engine’s optimizer decides how to execute it:

SELECT c.name, o.id, oi.product_id
FROM customers c
JOIN orders o     ON o.customer_id = c.id
JOIN order_items oi ON oi.order_id = o.id
WHERE c.id = 42;

The costs follow from the same structure. Changing the shape of the data means a schema migration, which ships as a coordinated release. Scaling writes past one machine takes real work, usually sharding or partitioning with the application aware of the split. And relationship questions that traverse several hops degrade badly: each additional hop is another self-join or another level of a recursive CTE, and the plan grows harder for the optimizer to handle as depth increases.

None of this has dislodged the model. PostgreSQL was the most-used database among all respondents in the 2025 Stack Overflow Developer Survey at 55.6%, with MySQL and SQLite behind it, and relational engines remain the default for transactional workloads. The relational database is the default worth departing from deliberately. For the full comparison against the alternatives, see SQL vs NoSQL databases.

NoSQL databases

NoSQL (“not only SQL”) is an umbrella for the non-relational databases that emerged in the late 2000s to serve workloads relational systems handled awkwardly: write throughput beyond one machine, horizontal scale across commodity hardware, and records whose shape changes often. The label marks that generation rather than everything that is not relational, which is why the two older non-relational models in this list, hierarchical and object-oriented, sit outside it even though they also store data without tables and joins. The next four sections cover its families, which is why both the umbrella and its members appear in this list.

The historical trade-off behind the category is consistency. The CAP theorem, formalized by Gilbert and Lynch, holds that a distributed system facing a network partition must choose between consistency and availability. Systems built to stay available across many nodes therefore relaxed consistency to eventual, described at the time by the BASE model (basically available, soft state, eventual consistency) in contrast to ACID.

That contrast has narrowed considerably. Mainstream document stores now support multi-document transactions, wide-column stores offer per-query tunable consistency, and several NoSQL systems provide strong consistency as a configuration rather than a redesign. Treating NoSQL as shorthand for no transactions describes the category as it stood over a decade ago rather than as it ships now.

What remains true is that the label carries little information on its own. A key-value cache and a graph database share almost nothing beyond not being relational: different storage layouts, different query surfaces, different failure modes, different reasons to exist. Choosing NoSQL is not a decision; choosing a family is.

Document databases

A document database stores each record as a self-contained document, typically JSON or a binary encoding of it such as BSON. A document holds its own nested structure, so an order and its line items live together and a read that needs the whole object touches one record.

{
  "_id": "ord_10482",
  "customer": { "id": 42, "name": "Ana Ruiz" },
  "items": [
    { "sku": "KB-118", "qty": 1, "price": 89.00 },
    { "sku": "MS-204", "qty": 2, "price": 24.50 }
  ],
  "status": "shipped"
}

The defining modeling decision is embedding versus referencing. Embedding nested data keeps reads to a single document and is the reason the model performs well on object-shaped access. Referencing other documents by identifier keeps each fact in one place but pushes the assembly work to the application or to an aggregation stage. Document engines add secondary indexes on nested fields and aggregation pipelines for grouping and reshaping, so the model handles more than key lookups.

The limits track the same decision. Embedded data is duplicated data, so a change to a value that appears in many documents becomes a fan-out write rather than a single update. Documents that grow without bound, an activity log embedded in a user record for instance, run into per-document size limits and rewrite costs. And queries that span collections are the weak spot: joins exist in modern engines but are not the model’s strength, so a workload dominated by cross-entity questions is fighting the design.

Document databases fit content management, product catalogs, user profiles, event payloads, and any domain where records are read as whole objects and their fields vary between instances. MongoDB, Couchbase, Firestore, and Amazon DocumentDB are the common implementations.

Key-value databases

A key-value store maps a key to a value. In the pure model the database treats that value as opaque, so it does not parse it, index inside it, or let you query by its contents. That constraint is the entire point: lookups are effectively constant-time, the code path is short, and the store is easy to distribute by hashing keys across nodes.

Because the key is the designed access path, key design carries the whole access pattern. A key like session:9f2c or user:42:preferences encodes the question the application will ask, and any access pattern the key scheme did not anticipate requires either a second key space maintained on write or a full scan. Most engines add time-to-live expiry and eviction policies, which is why the model dominates caching and session storage.

The two variants differ in where data lives. In-memory stores such as Redis and Memcached keep the working set in RAM for latency measured in microseconds. Redis adds optional persistence, either point-in-time snapshots or an append-only log, so a restart can reload the dataset; Memcached is a cache with no durability guarantee, and its own documentation is explicit that warm restart does not make it crash safe. Managed stores such as Amazon DynamoDB persist to disk and replicate across nodes, trading some latency for durability and elastic scale.

The limits are the constraint restated: no ad-hoc queries, no relationships between records, and no server-side filtering, so any logic beyond “get me the value at this key” belongs to the application. Secondary index support exists in some products but varies, and relying on it moves the workload toward what a document store already does well. Typical uses are caching, session state, feature flags, rate-limit counters, and service discovery, where etcd fills the same shape for cluster configuration.

Wide-column databases

A wide-column store groups related columns together and addresses them by a key that decides placement. The vocabulary differs by product: HBase and Bigtable organize columns into column families under a row key, while Cassandra and ScyllaDB speak of tables whose primary key splits into a partition key that decides which node holds the data and clustering columns that decide the on-disk sort order within that partition. The shape is the same in each: a key that places the data, and columns grouped for the reads they serve.

CREATE TABLE events_by_device (
  device_id   uuid,
  event_time  timestamp,
  event_type  text,
  payload     text,
  PRIMARY KEY ((device_id), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

That layout makes the model’s discipline explicit: data modeling is query-driven, as Cassandra’s documentation puts it, and tables are designed per query rather than per entity. The same facts get written into several tables shaped for the reads they serve, because the system has no foreign keys and no relational integrity to reconstruct them at query time. Writes are cheap enough for this to be a reasonable trade: across the category, a log-structured write path appends rather than updates in place. Beyond that the designs diverge. Cassandra and ScyllaDB are masterless, so any node accepts writes and consistency is tunable per operation; HBase and Bigtable route each region or tablet through a single serving node, and consistency is set by the deployment.

Wide-column is not the same as columnar. The names collide but the systems solve different problems. Wide-column stores such as Apache Cassandra, HBase, ScyllaDB, and Bigtable group related columns under a placement key and are built for high-volume operational reads and writes. Columnar (or column-oriented) analytical systems store each column’s values contiguously so that a scan reads only the columns a query references: ClickHouse, the cloud warehouses with their own columnar formats (Snowflake’s micro-partitions, BigQuery’s Capacitor, Redshift’s columnar blocks), and the Parquet-backed tables behind most lakehouses. One is an operational store partitioned by key; the other is an analytical layout optimized for scanning few columns across many rows. Choosing one when you needed the other is a common and expensive mistake.

The costs are the flip side of query-first modeling. The access patterns have to be known in advance, ad-hoc questions arrive without a table to answer them, and denormalized copies mean updates fan out. Wide-column stores fit time-series and event data, messaging and activity feeds, telemetry at high ingest rates, and any workload where write volume is the binding constraint and the queries are known.

Graph databases

A graph database stores nodes and edges as first-class objects, both carrying properties. A relationship is stored explicitly, with a name and a direction of its own. In engines that keep adjacency in the storage layer, that makes traversing from one entity to its neighbors a local operation whose cost tracks the number of connections involved rather than the size of the tables holding them, so the cost of a multi-hop question grows with the answer rather than with the data. How far a given product delivers that depends on how it stores the graph.

Two data models share the label. The labeled property graph, used by most operational graph databases, attaches key-value properties directly to nodes and edges. RDF represents everything as subject-predicate-object triples and comes from the semantic web lineage, with SPARQL as its query language and formal ontologies and inference as its strength. The comparison between property graphs and RDF covers where each fits.

On the query side, the property graph world has consolidated. openCypher is the open specification of the pattern-matching language Neo4j originated, Gremlin is Apache TinkerPop’s traversal language, and ISO published GQL as ISO/IEC 39075 in April 2024, which Neo4j describes as the first new ISO database language since SQL. A traversal reads as the shape you are looking for:

MATCH (u:User {email: $email})-[:LOGGED_INTO]->(:Host)-[:CONNECTS_TO*1..3]->(s:Service)
WHERE s.tier = 'critical'
RETURN DISTINCT s.name

Implementations differ in how they store the graph underneath. Native graph systems keep adjacency in the storage layer so that following an edge is a pointer traversal, while non-native ones layer a graph API over a relational or key-value engine and reconstruct adjacency as they go. Neo4j, which sells a native engine, sets out that distinction in its write-up on native versus non-native graph technology. The category spans Neo4j, Amazon Neptune, TigerGraph, JanusGraph, and embedded engines such as Kuzu, whose upstream project was archived in 2025 and now continues through community forks; our roundup of popular graph databases covers the field, and when a graph database makes sense covers the adoption question.

The honest cost is operational. A graph database is another store to run, and the data has to get into it. For records whose system of record is a relational database, a warehouse, or a lakehouse, that means an ETL pipeline, a second copy, and an ongoing synchronization problem. Teams weigh that against the traversals they wanted and frequently decide to write the recursive SQL instead.

That constraint is not fixed. PuppyGraph applies the graph model as a query layer over data that already lives in a SQL database, warehouse, or lakehouse, including direct reads of open table formats like Iceberg and Delta Lake. You define a graph schema mapping existing tables to nodes and edges, then query it in openCypher or Gremlin with no data movement and no second store to keep in sync. A query compiles into a plan of node and edge operators that execute in its own distributed engine, and the underlying sources see only simple projection and filter SQL. Because the query is represented as graph operators end to end, the engine optimizes specifically for multi-hop traversals, which is where its traversal performance comes from. AMD uses it to build a graph layer over Apache Iceberg spanning tickets, code, logs, and telemetry.

Object-oriented databases

An object-oriented database stores objects the way an application defines them: with identity, attributes, inheritance, and in some systems behavior, persisted directly rather than decomposed into rows and columns. The motivation was the object-relational impedance mismatch, the translation layer every application writes to flatten an object graph into tables and reassemble it on read. The category’s requirements were set out in the 1989 Object-Oriented Database System Manifesto, which named complex objects, object identity, encapsulation, inheritance, and persistence among the features a system needed to qualify.

The mainstream answer turned out to be different. Object-relational mappers made the translation cheap enough that teams kept the relational engine and its ecosystem of tooling, transactions, and SQL skills, and relational vendors absorbed parts of the object model rather than ceding the ground: SQL:1999 defined type inheritance, and PostgreSQL ships table inheritance along with composite and user-defined types. The result is that the object features most applications wanted became available inside the database they were already running.

Object databases persist where the object model is the point. ObjectDB is a current implementation, InterSystems IRIS carries an ODMG-based object model inside a multi-model engine, the Versant lineage is still sold as Actian NoSQL, and engineering, scientific, and telecom domains with deeply nested structures remain the natural fit. Treat this type as superseded for general-purpose use rather than obsolete: it lost the mainstream to relational-plus-ORM, and it still serves workloads where object identity and inheritance are the data’s actual shape.

Hierarchical databases

A hierarchical database organizes records into a tree in which each child has exactly one parent. Access is navigational: you enter at a root segment and follow the predefined path down, which makes reads along that path fast and predictable and makes anything else difficult.

The canonical system is IBM’s Information Management System. IBM built it with Rockwell and Caterpillar to track the bills of material for the Apollo spacecraft and the Saturn V second stage, and the system broadcast its first ready message at Rockwell’s Space Division in Downey, California, in August 1968. It is not a museum piece: IMS remains a current IBM product, running high-volume transaction workloads on z/OS at banks, insurers, and retailers whose core systems were built around it.

The single-parent rule is the model’s defining limit. Many-to-many relationships, a student enrolled in several courses being the textbook case, do not fit a tree without duplicating data. That constraint motivated the CODASYL network model, where a record type can be a member of several owner-coupled sets at once, though a true many-to-many still required a third intersection record type there. The relational model arrived with a different motivation, removing the ordering, indexing, and access-path dependence that navigational systems built in, and resolving relationships at query time instead of storing them as paths. Ad-hoc queries are the other weak point, since a question that does not follow an existing path has no efficient way through the tree.

The model itself is more common today than the database category. LDAP directories and Active Directory organize entries in a hierarchy, DNS resolves names down a tree of zones, filesystems nest directories, and the nested structures inside JSON and XML documents are hierarchies with a different name. When a domain genuinely is a containment tree, the shape is still the right one; what changed is that dedicated hierarchical DBMS products are no longer the way most teams reach for it.

Operational databases

Operational is a workload role rather than a data model. An operational database is one serving live application traffic, and it can be relational, document, key-value, or wide-column underneath. What defines it is the workload: OLTP, short read and write transactions, high concurrency, and latency budgets measured per request.

The engineering follows from that profile. Storage is usually row-oriented so that reading or writing one record touches one place on disk. Indexes are tuned for point lookups and small range scans rather than full scans. Transaction isolation and locking matter because many clients touch the same records concurrently. And capacity is planned around a steady arrival rate of small operations rather than around a few large ones.

The counterpart is the analytical workload, OLAP, which asks aggregate questions across large row counts: revenue by region by quarter, cohort retention, funnel conversion. Those queries scan far more rows and touch far fewer columns, which is what columnar storage and data warehouses are built for. Running them against the operational store is the classic mistake, since one analyst’s full-table scan competes for the same resources as customer-facing writes. The usual separation is an operational store for live traffic plus a warehouse or lakehouse fed from it, though HTAP systems aim to serve both from one engine and accept the design compromises that requires.

This is why the operational label belongs in a list of database types even though it names something different from the other eight. The operational-versus-analytical split is usually the first decision a team makes, ahead of any data model question, and it determines which half of the stack the model choice happens in.

Conclusion

The nine types answer three different questions, and separating them makes the list usable. Seven describe how records are structured: tables, documents, key-value pairs, column families, nodes and edges, objects, trees. NoSQL names the umbrella over four of them and tells you little on its own. Operational names the workload role, which cuts across every model above it. A shortlist that works decides the role first, then the model, then the product.

Within the model choice, the question worth asking is which access pattern needs to be cheap. Reading whole objects points to documents, lookups by known key to key-value, high-volume writes against known queries to wide-column, aggregate scans to columnar analytical stores, and questions about connections to graphs. Correctness under concurrency keeps pointing back to relational, which is why it remains the default for systems of record and why most architectures end up polyglot rather than uniform. One shift worth noting for the last of those patterns: relationship queries no longer require standing up a separate store, because the graph model can arrive as a query layer over tables that stay where they are.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, so adding the graph model to your stack does not mean adding another database to it.