Types of Databases

A database is not just a place to store data. It is a set of tradeoffs about how data is structured, how it is queried, how failures are recovered, and which access patterns are cheap. Different database types exist because the same engine cannot optimise equally well for bank transfers, analytics dashboards, social graphs, and high-volume key lookups.

Relational databases

Relational databases store data in tables with fixed schemas and use joins, constraints, and transactions to keep that data consistent. They are strong when correctness matters more than schema flexibility. Orders, payments, account balances, and inventory systems often fit here because the database can enforce foreign keys, uniqueness, and atomic updates.

The tradeoff is that relational systems ask you to model data carefully up front. They scale very well vertically and can scale horizontally in some patterns, but cross-shard joins and globally consistent transactions become harder as the system grows. A relational database is usually the default choice when you need precise writes, rich querying, and clear integrity guarantees.

OLAP and analytical databases

Online Analytical Processing, usually shortened to OLAP, focuses on large scans, aggregates, and reporting rather than high-frequency transactional writes. These systems often store data in columnar form so queries can read only the columns they need. That makes sums, filters, and time-based analysis much faster for large datasets.

An OLAP store is a poor fit for a hot user-facing checkout path, but it is excellent for questions such as "what was revenue by region over the last 90 days?" The operational pattern is often to copy or stream data from transactional systems into a warehouse or lakehouse, transform it, and run analytics there. The extra pipeline adds latency and complexity, but it protects the transactional system from heavy analytical load.

NoSQL families

NoSQL is an umbrella term, not a single design. It usually means the database gives up some relational features in exchange for a simpler scaling model or a data model better suited to the workload.

Key-value stores map one key to one value. They are fast, simple, and easy to partition. Caches, session stores, and feature flag lookups are classic examples. Their weakness is limited query flexibility. If you need to find records by many secondary attributes, a pure key-value store becomes awkward quickly.

Document databases store self-contained records, often in JSON-like form. They work well when each object has a natural boundary and the schema evolves over time, such as product catalogues or content metadata. The tradeoff is that cross-document relationships are weaker than in a relational model, so consistency across many documents often moves into application code.

Wide-column databases group data by primary key and organise related values efficiently for massive write throughput and predictable range access. They are common in telemetry, event storage, and large distributed services. The price is that data modelling becomes query-first. You often duplicate data deliberately so the read path stays cheap.

Graph databases treat relationships as first-class data. They are useful when the links between entities matter as much as the entities themselves, such as fraud detection, recommendation engines, or network topology. Graph traversal can be elegant and fast, but graph systems are rarely the best general-purpose store for everything else.

Specialised stores and choosing well

There are also purpose-built databases for search, time-series data, vectors, and geospatial queries. These exist because indexing and storage layouts can be tuned for one dominant pattern. A search engine, for example, cares about token indexes and relevance scoring more than multi-row transactions.

The practical question is not "which database type is best?" It is "which failure or cost are we willing to accept for this workload?" If you need transactional integrity, use a relational database first. If you need cheap analytics over large historical data, use an OLAP system. If you need simple horizontal scale around a narrow access pattern, a NoSQL design may be the better fit. Good architectures often use several database types at once, each for the job it makes cheap and predictable.