Types of databases: what each one is for, and which ones a business needs

"What database should we use?" sounds like one question and is really nine. Databases come in types because the jobs differ: recording a payment safely, fetching one record in a millisecond, tracing who is connected to whom, searching text, or summing a billion rows for a board report. Knowing the types lets a non-specialist follow a technical proposal and ask whether a new database is needed at all.

What are the main types of databases?

The nine types below cover almost everything a company will meet. The table gives the main strength of each, well-known products, a typical business use and, most useful, when to avoid it. The product names come from the ranking in the 2026 Stack Overflow Developer Survey and the vendors' own documentation.

Products overlap. Redis describes itself as an in-memory data store used as a cache, vector database, document database, streaming engine and message broker, and Elasticsearch now stores vector data too. Treat the types as jobs, because one product may do several.

When is a relational database the right choice?

Almost always, for the data that runs the business. A relational database stores data in tables linked by keys and queried with SQL. It enforces rules such as "every invoice has a customer" and keeps groups of changes all-or-nothing. The PostgreSQL project says its database has been ACID-compliant since 2001, and it supports document, key-value and other data types inside the same system.

It is also the safest choice for people. In the Stack Overflow survey, PostgreSQL ranked first at 57.9%, followed by SQLite at 42.1% and MySQL at 35.1%. Engineers who know these systems are easy to find, and nearly every business tool can connect to them. Our guide to SQL vs NoSQL covers the decision in more depth.

What are document and key-value databases good for?

A document database stores each record as a self-contained document. MongoDB's guidance is that data accessed together should be stored together, and that documents in one collection need not share the same fields. That suits content and catalogs where each item has its own shape.

A key-value database stores a value against a unique key, much like a very fast filing cabinet where you must know the label. AWS describes the key as the unique identifier for each value. Redis keeps data in memory, which is why teams use it as a cache that spares the main database from repeated reads. DynamoDB is the key-value service most AWS shops meet.

Both types are weak at questions you did not plan for. If finance asks for margin by region and customer segment, a key-value store cannot answer without exporting the data somewhere else.

When do wide-column, graph and time-series databases make sense?

These three solve narrower problems, and most companies of 20 to 200 people will never need one.

Wide-column databases such as Apache Cassandra spread data across many servers. Cassandra describes itself as a NoSQL distributed database with a masterless architecture, where a partition key distributes data among nodes. Discord is a published example. Its engineering blog (March 6, 2023) says it ran 12 Cassandra nodes in 2017 storing billions of messages and 177 nodes by early 2022 storing trillions, then moved to ScyllaDB, a Cassandra-compatible database, which brought the cluster to 72 nodes. The same post lists the costs of running Cassandra at that size: hot partitions, garbage collection pauses and compaction backlogs.

Graph databases store connections directly. Neo4j explains that its graphs hold nodes, relationships and properties, and that they do not use JOINs. They fit questions like "which accounts share a phone number, an address and a device." They are a poor fit when your data is mostly records and few questions concern the links.

Time-series databases handle measurements stamped with time. InfluxData says InfluxDB 3 Core is purpose-built for real-time data monitoring and recent data, and Tiger Data documents TimescaleDB with hypertables for time-series data. Machine sensors, application metrics and usage telemetry are the typical loads.

What do search, vector and columnar analytical databases do?

Search databases make large amounts of text findable. Elastic describes Elasticsearch as an open source, distributed search and analytics engine, and its documentation says a stored document becomes searchable in near real time, within 1 second. Use one to power site search or search across large document sets, and keep the original data in a system of record.

Vector databases store numeric representations of meaning, called embeddings, so that software can find content similar in meaning rather than matching exact words. This is the retrieval step behind most AI knowledge assistants. The pgvector extension adds vector types to PostgreSQL and performs exact nearest-neighbor search by default. Adding an HNSW or IVFFlat index switches to approximate search that trades some recall for speed. Our guide to RAG vs fine-tuning explains where this fits.

Columnar analytical databases store each column's values together, so a query that sums one column over millions of rows reads far less data. ClickHouse describes itself as a column-oriented SQL database for online analytical processing, and notes that the layout makes it harder to restore single rows. That trade-off defines the type: excellent for reporting, wrong for the live application.

Can PostgreSQL replace several of these databases?

At small and moderate scale, often yes. PostgreSQL is built to be extended: the CREATE EXTENSION command loads new data types, functions, operators and index support into a database. That is why one Postgres server can cover several jobs from the table above.

Extensions must be supported by your host, so check your managed provider's extension list before relying on one. Scale limits also apply. pgvector, for instance, can index vectors of up to 2,000 dimensions, and extension performance at very large volumes differs from purpose-built systems. For graph, wide-column and columnar analytical workloads, a dedicated system is usually the better answer once data is large.

The practical advice: resist adding a new database. Each one means another bill, another backup plan, another set of credentials, another upgrade schedule and another person who has to understand it. Add one when you can show that the database you have cannot meet a measured need.

How many databases should a 20 to 200 person company run?

Fewer than the architecture diagrams suggest. A relational system of record handles most of the load. A cache is the most common addition, followed by a search index or reporting store if a real need appears.

Illustrative example: A 70-person logistics company is told it needs a document database for shipment records, a graph database for route planning, a search engine for the customer portal and a vector database for an AI assistant. Four new systems would mean four more things to secure, back up and staff. The team reviews the actual needs instead. Shipments fit tables and need transactions, so they stay in PostgreSQL. Portal search covers a few hundred thousand records, which built-in full text search handles. The AI assistant searches a few thousand documents, which pgvector handles. Route planning uses a specialized solver and needs no database change. They run one database, plus a cache after page load times are measured.

Real companies at huge scale choose differently, because their numbers differ. Notion's engineering team wrote in October 2021 that it split its Postgres data into 480 logical shards across 32 physical databases. It stayed on one database family and spread the load. Discord moved to a database built for its message volume. Both decisions followed measured limits at very large size.

How do you choose a type of database?

1. Name the workload. Is it recording transactions, looking up by key, searching text, finding similar items or analyzing history?
2. Default to relational for the system of record.
3. Check whether a PostgreSQL feature covers the need at your data volume.
4. Measure before adding. Run the real queries on realistic data and write down the number that failed.
5. Name an owner and a recovery plan for every database you add, including how it is backed up and who is called when it breaks.

How Kastling approaches database choices

Choosing and connecting databases is part of the design work in Custom Solutions, alongside internal tools, dashboards and portals. Kastling would start with the work the system supports and the records it must keep correct, connect the systems already in use, and pick the smallest set of databases that meets the need. Each added database would have a named owner, and success would be agreed in measurable terms. For the migration side, see our guide to moving a legacy application to the cloud.