- Core Properties: Enforces ACID (Atomicity, Consistency, Isolation, Durability). Guarantees immediate consistency; a transaction either fully completes or fully rolls back.
- Scalability Model: Primarily vertical (scaling up hardware like CPU, RAM). Horizontal scaling is difficult and expensive due to strict consistency requirements.
- Structure: Rigid, schema-based design. Data is stored in normalized tables with strict row/column constraints and foreign key relationships.
- Expanded Examples: Oracle DB, PostgreSQL, MySQL, Microsoft SQL Server, MariaDB.
- Target Use Cases: Banking, e-commerce checkout systems, ERP software, inventory management, or any domain where data integrity failure results in severe system or financial impact.
- Core Properties: Operates on the BASE model (Basically Available, Soft state, Eventual consistency). Sacrifices immediate consistency to achieve high availability and partition tolerance under network failure.
- Scalability Model: Native horizontal scaling (scaling out by adding commodity servers to a cluster). Data is distributed via sharding.
- Target Use Cases: Social networks, IoT sensor telemetry, real-time analytics, user session caching, high-throughput log aggregation.
NoSQL Subtypes & Expanded Examples:
-
Key-Value Stores: Data accessed via a unique primary key. Optimized for extremely low-latency reads/writes of unstructured blocks.
-
Examples: Amazon DynamoDB, Redis, Memcached, Riak.
-
Column-Based (Wide-Column): Stores data in column families. Optimized for fast reads of specific attributes over massive datasets and high write throughput.
-
Examples: Google Cloud Bigtable, Apache Cassandra, Apache HBase, ScyllaDB.
-
Document-Based: Stores semi-structured, hierarchical data in discrete documents (JSON, BSON, XML). Allows flexible schemas per document.
-
Examples: MongoDB, Apache CouchDB, Amazon DocumentDB, Firebase Firestore.
-
Graph-Based: Stores entities as nodes and relationships as edges. Optimized for traversing complex interconnections instantly without expensive join operations.
-
Examples: Neo4j, Amazon Neptune, ArangoDB, TigerGraph.
Start at Question 1.
1. Does the application require strict ACID compliance, complex multi-table transactions, and immediate consistency?
- YES: Select Relational DB (e.g., PostgreSQL, Oracle).
- NO: Proceed to 2.
2. Does the core functionality revolve around traversing highly interconnected data, discovering patterns, or mapping relationships (e.g., recommendation engines, fraud detection)?
- YES: Select Graph DB (e.g., Neo4j).
- NO: Proceed to 3.
3. Does the data model require extreme read/write speeds for simple data structures, often used for caching or session state management?
- YES: Select Key-Value Store (e.g., Redis, DynamoDB).
- NO: Proceed to 4.
4. Is the application storing massive, continuously growing volumes of time-series data, logs, or metrics requiring high write throughput across distributed nodes?
- YES: Select Column-Based DB (e.g., Cassandra, Bigtable).
- NO: Proceed to 5.
5. Is the application data naturally represented as hierarchical objects with rapidly evolving schemas where different records require different fields?
- YES: Select Document DB (e.g., MongoDB).
- NO: Re-evaluate data constraints; default to Relational DB if schema requirements can be formalized, or Document DB if rapid iteration is required.