Databases

A database scaling strategy where write operations can be committed concurrently to multiple active nodes.

AWS's managed relational database — Postgres, MySQL, and friends with backups, patching, and failover handled, so you run schemas instead of servers.

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.

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.

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.

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.

A wide-column database built for massive write throughput and no single point of failure — masterless, tunably consistent, and unforgiving of bad data modeling.

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.

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.

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.

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.

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.

Keeping copies of a database on multiple servers for availability, read scaling, and disaster recovery — with consistency as the price of admission.

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.

AWS's managed MongoDB-compatible database — Aurora-style storage with the Mongo API on top, and a compatibility asterisk you must test against.

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.

AWS's managed Redis and Memcached — in-memory caching that turns millisecond database queries into microsecond lookups, with cache-invalidation as the eternal catch.

A purpose-built time-series database for metrics and sensor data — fast timestamped ingestion and time-window queries, with cardinality as its defining constraint.

The write-optimized storage engine behind Cassandra, RocksDB, and most NoSQL — buffer writes in memory, flush to sorted files, compact in the background.

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.

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.

A database high-availability pattern maintaining synchronous standby database replicas in separate availability zones.

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.

Databases that trade SQL's relational model and strict consistency for horizontal scale, flexible schemas, or specialized data shapes.

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.

An asynchronous replication pattern offloading read-heavy query loads to read-only database copies.

The in-memory data-structures server that became infrastructure — cache, queue, rate limiter, session store, and leaderboard in one, with durability caveats to respect.

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 — record every change to a durable log *before* applying it, so a crash can always be recovered. The mechanism behind database durability itself.