Database Types (SQL, NoSQL & Beyond)
StorageThe system of record. Which data model you pick — relational, document, key-value, wide-column, graph, time-series, or vector — drives most of the rest of your design.
Databases are where correctness lives, and the first big decision is data model, not vendor. Relational (Postgres/MySQL) gives you a strong schema, joins, and ACID transactions — best when relationships between entities matter and you need multi-row consistency. Document stores (MongoDB) trade schema rigidity for flexible, denormalized documents that map naturally to app objects. Key-value stores (DynamoDB/Redis) are the simplest and fastest model — O(1) lookups by key, great for caching/session/profile data, but no querying by value. Wide-column stores (Cassandra/HBase/Bigtable) are built for huge write throughput and sparse schemas, partitioned by a row key with clustering columns for range scans. Graph databases (Neo4j) make relationships first-class, so multi-hop traversals (friends-of-friends, recommendations) that would need many joins in SQL become single traversals. Time-series databases (InfluxDB/TimescaleDB/Prometheus) are optimized for append-mostly, timestamped data with efficient range queries and downsampling/rollups. NewSQL (Spanner, CockroachDB, YugabyteDB) tries to give you relational semantics (SQL, ACID transactions) with horizontal scalability normally associated with NoSQL. Vector databases (Pinecone, pgvector, Milvus) index high-dimensional embeddings for approximate-nearest-neighbor search, the backbone of semantic search and RAG systems. Picking wrong here is expensive to undo later, so the model should be chosen from access patterns, not familiarity.
How it connects
Database Types (SQL, NoSQL & Beyond) as the source, with the components it typically interacts with.
- → Caching: A cache sits in front of the database to absorb read traffic and reduce latency for hot rows/queries.
- → Message Queues & Event Streaming: Writes are often committed to the database and then published as an event to a queue for downstream consumers (CDC / outbox pattern).
- → Sharding & Partitioning: When a single node can no longer hold the dataset or handle write throughput, the chosen data model is horizontally partitioned across shards.
- → Replication: Every production database needs replicas for durability and read scaling, regardless of which data model you picked.
- → CAP Theorem & PACELC: Every distributed database design is ultimately a concrete choice within the CAP tradeoff space (e.g. Cassandra favors AP, Spanner-style systems favor CP).
- → Distributed Transactions (2PC & Saga): Operations spanning multiple shards or services need a distributed transaction protocol (2PC/sagas) to keep the database consistent.