Databases
Managed data stores and database architectures.
29 terms
Database choices are some of the hardest to reverse in a running system, which makes the trade-offs here worth understanding before you're locked in rather than after. Relational databases give you strong consistency and joins at the cost of harder horizontal scaling; NoSQL trades some of that consistency and query flexibility for scale and simpler operations; vector databases exist specifically for similarity search over embeddings, which is a different access pattern from either.
This category also covers the mechanics that make databases reliable at scale — sharding, replication, write-ahead logging — and, increasingly, the vector-search infrastructure (HNSW indexes, cosine distance, pgvector) that RAG and AI-search systems depend on. Several entries here are referenced directly from the AI Fundamentals category for exactly that reason.
- Active-Active Replication
A database scaling strategy where write operations can be committed concurrently to multiple active nodes.
- Amazon RDS
AWS's managed relational database — Postgres, MySQL, and friends with backups, patching, and failover handled, so you run schemas instead of servers.
- Amazon Redshift
AWS's petabyte-scale data warehouse — columnar, massively parallel analytics on data too big for a transactional database, and the wrong tool for anything transactional.
- Athena
AWS's serverless SQL engine that queries data directly in S3 — no clusters to run, billed at $5 per terabyte scanned, which makes file format your real query optimizer.
- Aurora Serverless
Amazon Aurora that scales its capacity up and down automatically — even to zero — instead of running a fixed instance. Great for spiky or intermittent loads, tricky for steady ones.
- BigQuery
Google's serverless data warehouse — run SQL analytics over terabytes to petabytes with no infrastructure to manage, priced mainly by data scanned. Powerful for analytics, wrong for transactions.
- Cassandra
A wide-column database built for massive write throughput and no single point of failure — masterless, tunably consistent, and unforgiving of bad data modeling.
- Cloud Spanner
Google's globally-distributed relational database that scales horizontally while keeping strong consistency and SQL — famously breaking the 'you must give up consistency to scale' assumption, at a premium.
- Cloud SQL
Google Cloud's managed relational database (MySQL, PostgreSQL, SQL Server) — GCP's equivalent of Amazon RDS. You run schemas; Google runs the servers, backups, and failover.
- Connection Pooling
Reusing a fixed set of established database connections instead of opening one per request — the difference between a database that scales and one that falls over at 100 connections.
- Consistent Hashing
A hashing scheme where adding or removing a node reshuffles only a small fraction of keys — the distribution primitive behind sharded databases, caches, and CDNs.
- Cosmos DB
Azure's globally-distributed, multi-model database with turnkey global replication and five tunable consistency levels. Powerful and pricey — and the pricing punishes bad modeling.
- Database Replication
Keeping copies of a database on multiple servers for availability, read scaling, and disaster recovery — with consistency as the price of admission.
- Database Sharding
Splitting one logical database across many machines by partitioning the data — the way past a single server's limits, and a decision that reshapes your entire application.
- DocumentDB
AWS's managed MongoDB-compatible database — Aurora-style storage with the Mongo API on top, and a compatibility asterisk you must test against.
- DynamoDB
AWS's fully-managed key-value/document database — single-digit-millisecond latency at any scale, priced by throughput, and only fast if you model around its access patterns.
- ElastiCache
AWS's managed Redis and Memcached — in-memory caching that turns millisecond database queries into microsecond lookups, with cache-invalidation as the eternal catch.
- InfluxDB
A purpose-built time-series database for metrics and sensor data — fast timestamped ingestion and time-window queries, with cardinality as its defining constraint.
- Log-Structured Merge-Tree (LSM Tree)
The write-optimized storage engine behind Cassandra, RocksDB, and most NoSQL — buffer writes in memory, flush to sorted files, compact in the background.
- Memcached
A bare-bones in-memory cache — pure key-value, multithreaded, no persistence, no data structures. Fast and simple, and that simplicity is the whole point.
- MongoDB
The dominant document database — stores flexible JSON-like documents instead of rigid tables. Great when your schema evolves fast; a trap when you actually needed relational.
- Multi-AZ Deployment
A database high-availability pattern maintaining synchronous standby database replicas in separate availability zones.
- Neo4j
The leading graph database — stores relationships as first-class data so traversals that would be brutal multi-join queries in SQL become fast, natural graph walks.
- NoSQL Database
Databases that trade SQL's relational model and strict consistency for horizontal scale, flexible schemas, or specialized data shapes.
- Read Replicas
Read-only copies of a database that receive the primary's changes and serve read traffic — the first and simplest database scaling move, bounded by replication lag.
- Read Replicas
An asynchronous replication pattern offloading read-heavy query loads to read-only database copies.
- Redis
The in-memory data-structures server that became infrastructure — cache, queue, rate limiter, session store, and leaderboard in one, with durability caveats to respect.
- TimescaleDB
A PostgreSQL extension purpose-built for time-series data — keeps full SQL and the Postgres ecosystem while adding automatic time-partitioning and massive ingest/query speedups for time-stamped data.
- Write-Ahead Logging (WAL)
Write-Ahead Logging — record every change to a durable log *before* applying it, so a crash can always be recovered. The mechanism behind database durability itself.