What Kinds of Databases Are There?

From Relational to Vector

Part 3 of 12 in "Databases for Non-Developers". This post explains why there are dozens of database product names, using the shape of your data and the kinds of questions you ask.

Deep dive: Choosing actual products and comparing their cost structures is covered in the modern cloud database selection guide.

---

Shoes are all made for walking, but hiking boots, sneakers, and dress shoes look very different. What matters isn't which shoe is "best" — it's where you'll go and what you'll do. Databases work the same way. There is no single database that's best for every situation.

Database types split roughly along two axes: the shape of the data you store (is it a table, a document, a web of relationships?) and the kinds of questions you ask most often (exact lookups, large-scale analysis, or meaning-based search?). Hold onto these two axes and you won't get lost in the forest of product names.

1. Relational databases: organized in tables and relationships

A relational database stores data in tables of rows and columns, and connects tables to each other. Think of separate customer, order, and product tables, linked by customer numbers or product numbers.

Customers table    Orders table            Products table
CustID | Name      OrderID | CustID→       ProdID | Name  | Price
                                ProdID→

It fits work that needs a fixed structure and accurate transaction processing (the transactions from Part 2). For decades it has been the proven standard for orders, payments, accounting, reservations, and member management. Because you find and manipulate data with a shared language called SQL, it's also called a SQL database.

Examples: PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database

2. Document databases: flexibly hold a bundle of information

A document database bundles everything about one person or one product into a single "document" and stores it that way. Picture an online catalog where every product needs different fields: shoes need sizes, laptops need memory capacity — and both fit in relatively easily.

It's useful for services where the data structure changes often, or where you read everything about one subject at once. But "flexible structure" doesn't mean "no rules needed." If you add fields without standards, the same piece of data piles up under several different names — a free-for-all folder becomes a junk drawer.

Examples: MongoDB, Couchbase

3. Key-value databases: find values fast by their name tag

A key-value database pairs a unique key with a value, like a locker number and what's inside. The structure is simple, but that's exactly why it reads and writes very fast. It can't do complex searches, but for "give me what's under this key" it's close to top speed.

It's widely used for login sessions, temporary shopping carts, and caching frequently requested results (keeping them ready in advance).

Examples: Redis, and certain usage patterns of Amazon DynamoDB

4. Wide-column databases: spread very large data wide across servers

A wide-column database is structured so each row can have different columns, and it's designed to split very large datasets across many servers. It's used by services that constantly ingest enormous streams of events, messages, and activity records.

Examples: Apache Cassandra, Google Cloud Bigtable

5. Graph databases: for data where the relationships are the point

A graph database stores people, products, accounts — any subject — as points, and the relationships between them as lines. It's strong at questions that follow relationships, like "find suspicious accounts connected to this one, up to three steps away." Finding "friends of friends of friends" is painfully slow in a relational database; for a graph database, that's its home turf.

It's used for social relationships, recommendations, financial fraud detection, knowledge graphs, and supply-chain analysis.

Examples: Neo4j, Amazon Neptune

6. Time-series databases: for values that keep accumulating over time

A time-series database is built for data recorded together with time: a smartwatch's heart rate, a factory's temperature, server usage, stock prices — data where when it was measured is the point.

It favors analysis based on time windows: "the average over the last hour," "compared to the same time last month." If you pile IoT sensor or server-monitoring data into a plain relational database, it quickly becomes unmanageable — time-series databases have compression and retention policies optimized for time-based data.

Examples: InfluxDB, TimescaleDB

7. Search databases: find it even when the exact words don't match

A search engine database is specialized for finding words inside documents quickly and ranking the most relevant results first. It fixes typos, and finds "jacket" products even when you search "jaket" — that kind of forgiving document search is its strength. It's used for product search, internal document search, and log analysis.

Examples: Elasticsearch, OpenSearch

8. Vector databases: find things with similar meaning

A vector database converts the features of text, images, and similar material into sets of numbers (embeddings) and stores them. Just as a user searching "how to get a refund" can surface the document "Returns and payment cancellation guide," it can find material whose meaning is close even when the words aren't an exact match.

It's used for retrieval-augmented generation (RAG) — letting generative AI answer questions from your internal documents — as well as recommendations and image search. It's the newcomer of the AI era, but there's an important caveat: moving all your core business records — customers, payments, permissions — into a vector database is usually not appropriate. It's often used alongside your existing databases (covered in detail in Part 12).

Examples: Pinecone, Weaviate, Milvus, as well as PostgreSQL and MongoDB with vector search features

Do you have to pick just one: SQL or NoSQL?

NoSQL is an umbrella term for databases that aren't relational. It doesn't mean "never uses SQL" — it's more accurately read as "Not Only SQL." These days many products adopt each other's features: relational databases can handle documents and vectors, and NoSQL products offer transaction features and query languages.

It's natural for a large service to use several types of databases together: orders in a relational database, login sessions in a key-value store, product search in a search engine. This is called polyglot persistence.

But as the number of types grows, so does the difficulty of operations, security, and keeping data consistent. Every additional database adds another target for backups, permissions, monitoring, and incident response. For a small service, starting with one familiar, general-purpose database may be the better choice.

Key takeaways Database types are divided by the shape of your data and the questions you ask most. Relational is strong for structure and transactions, document for flexible bundles, graph for relationship exploration, time-series for change over time, and vector for meaning-based search. The right answer isn't "the best database" but "the database that fits our data and our questions" — and every decision to add a type carries an operations-complexity cost.

Selection cues at a glance

Questions to think about

• What shape does our service's data mostly take — regular tables, varied documents, a web of relationships, or time-stamped measurements?
• Are the questions we ask most often exact lookups, large-scale analysis, or meaning-based search?
• How many databases are we using right now, and can we explain why each one was introduced?

Next post: Why operational databases and analytical data stores (warehouses and lakes) are separated.

---

Series contents

1. What Is a Database — How Is It Different from an Excel File?
2. How Databases Protect Accuracy
3. What Kinds of Databases Are There? ← You are here
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters
6. Data Models and Data Quality
7. What Is Data Governance?
8. Less Personal Data, Only What's Needed
9. The Basics of Data Security
10. Why Do Data Breaches Happen, and What Should You Do When One Does?
11. Cloud and Serverless Databases
12. Databases in the AI Era