Skip to main content

A Taxonomy of Databases

· 4 min read
tanzhuo

Databases can be classified along several dimensions, each reflecting differences in data model, processing capability, deployment style, storage medium, and application scenario. Understanding these categories helps you pick the right database when designing a system architecture.

By Data Model​

Relational Databases (RDBMS)​

Relational databases use the table as their core data structure, organizing data into rows and columns and using SQL (Structured Query Language) for querying and management. Tables are linked to one another through primary keys and foreign keys, enabling complex cross-table queries.

Their characteristics:

  • Clear, strongly constrained data structures
  • Support for complex queries (joins, aggregations, etc.)
  • Transactions and ACID guarantees
  • Well suited to structured data

Typical databases: MySQL, PostgreSQL, Oracle, SQL Server, and others.

Non-Relational Databases (NoSQL)​

NoSQL (Not Only SQL) databases drop the traditional relational table structure in favor of more flexible data models, built to handle large-scale data and high-concurrency access.

Their characteristics:

  • Flexible data structures
  • Strong scalability
  • Good performance under high concurrency
  • Usually weak or no transaction support

By Processing Style​

  • Transactional databases: support transactions and the ACID properties (atomicity, consistency, isolation, durability).
  • Non-transactional databases: no transactions or ACID guarantees, but higher performance and scalability in return.

By Deployment​

  • Single-node databases: deployed on one server, with all data and computation on a single node.
  • Distributed databases: spread data across multiple servers that coordinate over the network, achieving greater scalability and availability.

By Storage Medium​

  • In-memory databases: keep data in RAM, so reads and writes are extremely fast — e.g. Redis, Memcached.
  • Disk-based databases: persist data to disk or SSD — e.g. MySQL, PostgreSQL, Oracle.

By Access Pattern​

  • OLTP (Online Transaction Processing) databases serve online transactional systems.
  • OLAP (Online Analytical Processing) databases serve analytics and decision support — e.g. ClickHouse, Doris, StarRocks, Snowflake.

Typical Use Cases​

Relational Databases (RDBMS)​

  • Applications handling large volumes of structured data, such as finance, e-commerce, and logistics.
  • Applications requiring transactions and ACID guarantees, such as banking, telecom, and aviation.
  • Applications requiring complex queries and analysis, such as data warehouses and business intelligence.

Non-Relational Databases (NoSQL)​

  • Document databases: for semi-structured data, such as blogs, news, and comments.
  • Key-value databases: for simple key-value data, such as caching and session management.
  • Columnar databases: for large volumes of structured data, such as logs, events, and time-series data.
  • Graph databases: for complex, interconnected data, such as social networks, recommendation systems, bioinformatics, and network security.
  • Object databases: for applications that need object-oriented programming support, such as game development and multimedia applications.

In-Memory Databases​

  • Applications needing fast response times, such as high-concurrency transaction processing and real-time analytics.
  • Applications needing fast reads and writes, such as caching and session management.
  • Applications needing real-time computation and analysis, such as real-time risk control and real-time recommendations.

Distributed Databases​

  • Applications needing high availability and fault tolerance, such as distributed computing and distributed storage.
  • Applications needing large-scale data processing and analysis, such as big data and machine learning.
  • Applications needing multi-region deployment and data sharing, such as cloud computing and IoT.

Wrapping Up​

Databases can be sliced along many dimensions, and a single product often belongs to several categories at once — MySQL, for example, is a relational database, a disk-based database, and a transactional database all at the same time. When choosing one, don't obsess over the taxonomy itself; instead start from your data structure, consistency requirements, concurrency scale, and query patterns, and find the category that matches the business. Combining multiple databases in one system is also common in practice — Redis for caching, MySQL for business data, ClickHouse for analytical queries. Understanding what each category is for is what lets you make sound trade-offs in architecture design.

COMMENTS