What Are the Different Types of Databases (and What Is Each One For)?

Quick answer

• A database’s type is its data model: how records are shaped and which queries are cheap as a result. Storage engine and query language follow from that.
• Eight families cover production systems: relational, document, key-value, wide-column, graph, time-series, search, and vector.
• “NoSQL” is a marketing label grouping four unrelated data models. It tells you nothing about fit.
• Transactional (OLTP) and analytical (OLAP) is a second axis that cuts across families — the same data can need a row store for writes and a columnar store for aggregation.
• Most apps need one relational engine plus a cache; add a specialized store only when a specific query type is clearly the bottleneck.
• Each section below stands alone — read the family you’re considering and the ones next to it.

What defines a type of database

A database type is defined by its data model — the shape in which it stores records — because the data model determines which queries are cheap and which are impossible. A relational engine stores rows in tables and can join across them; a key-value store stores opaque values behind keys and cannot join at all. That difference is architectural, not a matter of tuning.

Three things travel with the data model:

• The query interface. SQL for relational engines; key lookups for key-value stores; traversal languages for graph databases; a JSON query language for document stores.
• The consistency model. Relational engines on a single primary give strong ACID guarantees. Distributed stores often trade strict consistency for availability, which surfaces as stale reads.
• The scaling direction. Row stores scale up (bigger server, read replicas), while document, key-value, and wide-column stores are designed to scale out by distributing keys across nodes.

Choosing a type is choosing which of those three you want, and accepting what comes with them.

Relational databases: Rows, tables, and joins

A relational database stores data in tables of rows and columns, enforces relationships between tables with foreign keys, and answers questions with SQL, including joins and aggregates. It is the default for application data because most application data really is relational: users have orders, orders have line items, line items reference products.

Use cases: transactional application data, anything with relationships and rules that must hold, reporting queries over structured data, and financial or inventory data where a wrong value is unacceptable. PostgreSQL and MySQL are the common choices; SQLite covers embedded and single-file use.

Where it struggles: horizontal write scaling. A single primary handles a lot, but spreading writes across nodes without manual partitioning is not what these engines do natively.

Document databases: Whole records as JSON

A document database stores each record as a self-contained document, usually JSON, and returns it whole without joins. The model fits data whose shape varies between records and which is nearly always fetched in its entirety.

Use cases: content management systems, product catalogs with inconsistent attributes per category, user profile blobs, event payloads, and application logs. MongoDB is the best-known implementation; Postgres’s JSONB column type covers a smaller version of the same need inside a relational engine.

Where it struggles: joins and ad-hoc analytics. If you find yourself loading related documents one at a time to reconstruct a relationship, you’ve chosen the wrong model — and you’ve recreated the N+1 query problem with no index that fixes it.

Key-value stores: Opaque values behind keys

A key-value store maps a key to a value and does that one operation extremely quickly. It usually keeps data in memory, which is why it answers in microseconds and why memory is the cost limit.

Use cases: caching computed results, session storage, rate-limit counters, feature-flag evaluation, distributed locks, and simple queues. Redis is the standard; Memcached covers pure caching.

Where it struggles: being the system of record. If losing the contents would mean losing data rather than recomputing it, you need durability guarantees that a cache-tuned store isn’t set up to provide by default.

Wide-column stores: Massive keyed datasets across nodes

A wide-column store organizes data into rows with a partition key and flexible column families, and distributes those rows across many nodes. Lookups by partition key are fast at sizes that stop fitting comfortably on one machine.

Use cases: very large event and time-series datasets, messaging and activity feeds, IoT telemetry, and any workload with a predictable key-based access pattern at high write volume. Cassandra and ScyllaDB are the classic open-source options; DynamoDB is the managed one.

Where it struggles: queries that weren’t designed in advance. Access patterns must be known before you model the data, because adding a new query often means a new table and a migration of existing records.

Graph databases: Relationships as first-class data

A graph database stores entities as nodes and relationships as edges, and traverses those edges as a native operation. Answering “how is A connected to B, and through what path” is one query rather than a recursive join chain.

Use cases: social networks, recommendation engines, fraud detection across accounts and devices, dependency and supply-chain analysis, and knowledge graphs. Neo4j is the common choice.

Where it struggles: bulk aggregation over large datasets. Traversing deep relationships is what it does; summing a billion rows is not.

Time-series databases: Values with timestamps, optimized

A time-series database stores timestamped measurements and is built around the queries those measurements produce: aggregates over a time window, downsampling old data, and retention policies that delete by age. Compression and partitioning are time-aware, which is what separates it from a relational table with a created_at column.

Use cases: infrastructure and application metrics, sensor and IoT readings, financial tick data, and usage metering. InfluxDB, TimescaleDB, and Prometheus’s storage layer are common; TimescaleDB is a Postgres extension, so it can live inside an engine you already run.

Where it struggles: being a general-purpose application database. It’s tuned for append-heavy measurement writes and windowed reads.

Search databases: Inverted indexes for text

A search database builds an inverted index — a map from each word to the documents containing it — so text queries, ranking, and fuzzy matching are fast. A relational LIKE '%term%' query scans rows and cannot rank by relevance.

Use cases: site and product search, log exploration, faceted filtering, and typo-tolerant matching. Elasticsearch and OpenSearch are the established options; Postgres’s built-in full-text search covers small and medium datasets without another service to run.

Where it struggles: transactional writes. Search indexes are usually a secondary copy of data whose source of truth lives elsewhere, which introduces synchronization to keep correct.

Vector databases: Similarity over embeddings

A vector database stores embeddings — numeric arrays produced by a model — and answers nearest-neighbor queries: given this vector, which stored vectors are closest. That operation is what retrieval-augmented generation is built on.

Use cases: semantic search, retrieval for AI assistants, recommendation by similarity, deduplication, and image or audio matching. Options include the pgvector extension inside Postgres and dedicated services such as Pinecone and Weaviate.

Where it struggles: replacing your application database. Vectors describe similarity, not truth; records, relationships, and constraints still belong in a relational engine, with the embedding stored alongside.

Transactional versus analytical: The axis that cuts across all eight

Above every family sits a second distinction. OLTP databases serve an application: many small reads and writes, single rows, low latency, strong consistency. OLAP databases serve analysis: few very large scans, aggregates over millions of rows, read-mostly. A row-oriented engine stores each record’s fields together and is fast at fetching one record; a columnar engine stores each field’s values together and is fast at summing one field across everything.

That’s why the same data often lives in two places — a row store for the app and a columnar store like ClickHouse for dashboards — with a pipeline moving records between them. The alternative, running analytical queries against your production database, competes with user traffic for the same resources.

Where this bites vibecoders

The failure mode isn’t picking an exotic engine — it’s not picking at all, then letting the assistant’s default decide the data model. Ask for a feature that stores records and you’ll often get documents, because a JSON blob is the least committal thing to generate; the schema can’t be wrong if there isn’t one. It works until the first question that requires a join, at which point the code loads related records one at a time in a loop, and there’s no index that makes that fast — the data model itself is the bottleneck. The same happens in reverse with a relational default: a genuinely keyed, high-volume lookup workload gets a table and a growing index it didn’t need. The tell in both cases is in the generated code: queries assembled in application code rather than expressed in the database, and access patterns that were never stated. Say what your queries will be before asking for storage, and the choice mostly makes itself.

Checklist

• Name the queries your app will run before choosing a data model.
• Default to relational for app data with relationships.
• Use a key-value store for caches and counters, not as the source of truth.
• Reach for a search index when LIKE scans become the bottleneck, not before.
• Keep embeddings next to the records they describe — pgvector covers most apps.
• Move analytics to a columnar store rather than running reports on the production database.
• Add a specialized engine for one clearly distinct job, not as a general replacement.
• Re-check the choice when the access pattern changes, since that’s what invalidates it.

FAQ

How many types of databases are there?

Eight families cover almost everything in production: relational, document, key-value, wide-column, graph, time-series, search, and vector. They differ in the data model, which determines which queries are cheap. The transactional-versus-analytical distinction cuts across all eight, so the same family can appear in both a row-oriented and a columnar form.

Is NoSQL one type of database?

No — NoSQL is a label for everything that isn’t a relational table-and-SQL engine, which lumps document stores, key-value stores, wide-column stores, and graph databases together. Those four have very different data models and very little in common beyond the marketing category. Choosing “a NoSQL database” is not a decision; choosing a document store over a key-value store is.

Which database type is best for AI applications?

Two, usually together. A relational database for the application’s own data, and a vector index for embeddings — which can be the same Postgres instance if you use the pgvector extension. That combination keeps one source of truth for records while supporting semantic retrieval over the embedding column.

Can one database be several types at once?

Increasingly, yes. PostgreSQL stores relational rows, JSON documents, full-text search indexes, and vectors; Redis offers streams and search alongside key-value. This multi-model trend means the practical question is rarely “which type” but “which engine, with which extensions, and which separate service for the workload it handles badly.”

Related topics

• How to Choose a Database for Your App: A Decision Guide
• How to Design a Database Schema (That You Won’t Have to Rewrite)
• The 12 Database Mistakes That Show Up in AI-Generated Apps
• Databases for AI Builders: Why Your AI-Generated App Gets Slow and Loses Data
• What Is Database Indexing (and Why Is My Query Slow)?
• What Is an ORM (and When Should You Use Raw SQL)?

Sources

• PostgreSQL Documentation — Data Types
• MongoDB Manual — Data Modeling
• Redis Documentation
• Neo4j Documentation — Graph database concepts
• pgvector — Open-source vector similarity search for Postgres
• Elasticsearch Guide — Inverted index
• Apache Cassandra Documentation