A database is a system for storing, updating and querying data in an organized way. But there is no single kind of database: relational systems, NoSQL families, in-memory engines and analytical stores are each designed for different needs. This guide classifies the main database types, explains where each family shines, and briefly introduces the popular products with links to deeper articles.
What Is a Database?
A database is a collection that holds related data in a structured form, on disk or in memory. The software that manages this data is called a database management system (DBMS). A DBMS handles writing, reading, updating and deleting data, concurrent access by many users, authorization and durability.
Most serious business applications want data integrity guaranteed by the ACID properties (Atomicity, Consistency, Isolation, Durability). Some distributed systems, by contrast, trade stronger guarantees for scalability by adopting looser consistency models (eventual consistency). Understanding this trade-off is decisive when choosing a database type.
The core difference between a database and a plain file (a text or spreadsheet file, say) lies in the guarantees a DBMS provides: locking under concurrent access, rollback on a partial update, authorization, and indexes optimized for querying. For a tiny data set a file may be enough; as data grows and multiple users connect, a DBMS becomes almost essential.
How Are Databases Classified?
Databases can be classified along several axes: by data model (relational, document, key-value, graph, columnar), by where data lives (disk-based or in-memory), by workload (transactional/OLTP or analytical/OLAP), and by architecture (single-node or distributed). The table below summarizes the main families.
| Family | Data model | Typical use | Examples |
|---|---|---|---|
| Relational (RDBMS) | Tables of rows and columns; SQL | Transactional apps, finance, ERP | PostgreSQL, MySQL, Oracle |
| NoSQL - Document | JSON-like documents | Content, catalogs, flexible schema | MongoDB, Couchbase |
| NoSQL - Key-Value | Key -> value pairs | Caching, sessions, counters | Redis, DynamoDB |
| NoSQL - Wide-Column | Wide column structures | Very high write volume, time series | Cassandra, HBase |
| NoSQL - Graph | Nodes and edges | Relationship-heavy data, recommendations, fraud | Neo4j |
| In-memory | Primarily in RAM | Low latency, real-time | Redis, Oracle TimesTen |
| Analytical (OLAP) | Mostly columnar storage | Reporting, data warehouse, BI | Vertica, DuckDB, SAP HANA |
Relational Databases (RDBMS)
Relational databases store data in tables; each table is made of rows (records) and columns (fields). Links between tables are established with primary and foreign keys. The standardized query language is SQL, and most systems support ACID transactions. A well-defined schema keeps data consistent and relationships intact.
-- A simple relational query: join customers with their orders
SELECT c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.name
ORDER BY order_count DESC;The relational model has long been the standard for accounting, e-commerce, ERP and general business applications where consistency is critical. Its strength is clarity and integrity; scaling out horizontally, however, can require extra design effort. Normalization reduces data duplication, indexes speed up queries, and transactions apply several changes as one unit or roll them all back.
A major advantage of relational systems is their maturity: an ecosystem built over decades, broad tooling, established backup and recovery practices, and a large community of experts. This makes them a reasonable starting point for most projects.
NoSQL Databases
NoSQL is an umbrella term for several database families that do not stick to a rigid relational schema. The goal is often flexibility and horizontal scalability. There are four main sub-families:
- Document databases: store data as JSON-like documents with a flexible schema. Common for content management and catalogs (e.g. MongoDB).
- Key-value stores: the simplest model, mapping a key to a value. Very fast for caching and session data (e.g. Redis).
- Wide-column stores: scale for very high write volumes and time-series data (e.g. Apache Cassandra).
- Graph databases: model relationships with nodes and edges; suited to social networks, recommendations and fraud analysis (e.g. Neo4j).
For scalability, NoSQL systems often offer looser consistency (eventual consistency) in some configurations. This can be an advantage in the right use case and a risk in the wrong one; the choice depends on business requirements.
NoSQL should be seen as complementary to relational databases, not a replacement for them. Many modern systems use several databases together in the same application (polyglot persistence): the transactional core in a relational system, the cache in a key-value store, and search in a separate engine.
SQL or NoSQL?
The choice between the two is usually not 'which is better' but 'which fits this job'. Relational systems stand out for strong consistency and complex relationships; NoSQL systems for a flexible schema and certain scaling patterns.
| Criterion | Relational (SQL) | NoSQL |
|---|---|---|
| Schema | Predefined, strict | Flexible, variable |
| Query language | Standard SQL | Product-specific API/query |
| Consistency | Usually strong (ACID) | Often tunable / eventual |
| Scaling tendency | Vertical; extra design to scale out | Designed to scale horizontally |
| Good fit | Finance, ERP, relational data | High volume, flexible/variable data |
In-Memory Databases
In-memory databases keep the primary copy of data in RAM rather than on disk. This removes disk latency, so reads and writes can complete with very low latency. The cost is that RAM is more expensive than disk and is not persistent; these systems therefore usually write a log or snapshots to disk for durability.
This family is preferred for caching, session management, real-time leaderboards, recommendation engines and low-latency transactional workloads. There are in-memory systems with a relational interface too; for related products, see What Is Oracle TimesTen? and What Is VoltDB?.
Analytical Databases (OLAP)
Analytical databases are built to run aggregation, grouping and reporting queries quickly over large numbers of rows. Most of them use columnar storage: because they store data column by column rather than row by row, they can read only the columns they need and scan large volumes efficiently. Unlike transactional (OLTP) systems, the goal is large-scale analysis, not single-record updates.
| Property | OLTP (transactional) | OLAP (analytical) |
|---|---|---|
| Purpose | Day-to-day operations, record updates | Reporting, bulk analysis |
| Typical query | Few rows, frequent writes | Many rows, read-heavy |
| Storage tendency | Mostly row-based | Mostly columnar |
| Example | Placing an order | Monthly sales trend report |
In this space, the MPP (massively parallel processing) system Vertica, the in-process analytical engine DuckDB, and the in-memory, columnar SAP HANA are prominent examples. DuckDB is often described as an embedded engine aimed at analytical workloads.
Popular Relational Database Products
The relational world spans a wide range, from open source to enterprise commercial systems. You can reach a detailed introduction to each of the most widely used products below:
- What Is PostgreSQL? - an extensible, standards-oriented open-source object-relational system.
- What Is MySQL? - a very widely used open-source relational database in web applications, now developed under Oracle.
- What Is MariaDB? - a community fork started by the original MySQL developers.
- What Is Percona Server for MySQL? - an enhanced, MySQL-compatible distribution.
- What Is Oracle Database? - an enterprise commercial database known for its broad feature set.
- What Is Microsoft SQL Server (MS SQL)? - Microsoft's enterprise relational database.
- What Is IBM Db2? - IBM's enterprise data platform.
- What Is IBM Informix? - an IBM database used in transactional and embedded scenarios.
- What Is Sybase (SAP ASE)? - a relational system continued today as SAP Adaptive Server Enterprise.
- What Is Firebird? - an open-source relational database derived from the InterBase codebase.
- What Is InterBase? - a lightweight, embeddable commercial relational database.
NewSQL and Distributed SQL
NewSQL is an approach that aims to combine the familiar consistency of the relational model and SQL with the horizontal scalability of NoSQL systems. These systems typically spread across multiple nodes while still offering ACID transactions and a SQL interface.
- What Is Google Cloud Spanner? - a globally distributed managed relational service that targets strong consistency.
- What Is OceanBase? - a distributed relational database designed for high scale.
- What Is VoltDB? - an in-memory, scalable SQL system for low-latency transactions.
Desktop and Embedded Databases
Not every database needs a separate server. Embedded and desktop databases live inside the application or on a single user's machine, with a low setup and administration burden. They are ideal for small applications, mobile software, prototypes and single-user scenarios.
- What Is SQLite? - a serverless, single-file, very widely deployed embedded database.
- What Is Berkeley DB? - a key-value data store embedded into applications.
- What Is Microsoft Access? - an Office component for desktop applications and small databases.
- What Is OpenOffice Base? - the database tool of the open-source office suite.
- What Is FileMaker? - a desktop and platform database focused on custom app development.
Cloud Database Services
Cloud providers offer databases as managed services: the provider takes on operational burdens such as backups, patching, scaling and high availability. This lets teams focus on the application instead of the infrastructure. Managed setups carry different advantages and trade-offs compared with running a database on your own server.
We examine options such as Google Cloud SQL, Azure SQL and Amazon RDS, along with when to choose a managed service versus your own server, in Cloud Database Services: Cloud SQL, Azure SQL, Amazon RDS.
How Do You Choose the Right Database?
There is no single 'best' database; the right choice depends on the workload. It helps to ask these questions when deciding:
- What is your data model? Strong relationships and consistency, or a flexible schema?
- Is your workload transactional (OLTP), analytical (OLAP), or a mix of both?
- What is your latency target? Do you need an in-memory layer?
- Is your scaling need vertical (a stronger single machine) or horizontal (many nodes)?
- Operating model: will it run on your own server or on a managed cloud service?
- License and cost: open source or commercial? How is the team's experience and the ecosystem support?