The four guarantees a transactional database promises: atomicity, consistency, isolation, durability.

The NoSQL counter-philosophy: Basically Available, Soft state, Eventually consistent — trade strong guarantees for availability and scale.

In the presence of a network partition, a distributed system must choose between consistency and availability — you can't have both.

An extension of CAP (Consistency, Availability, Partition-tolerance): under Partition choose A or C, Else (normal operation) choose Latency or Consistency.

Rows in typed tables with declarative joins, ACID transactions, and a schema enforced by the engine.

A hash map at planet scale: put(key, value), get(key), and not much else — but extremely fast and horizontally scalable.

Store self-contained JSON-ish documents per key, query on any field, no fixed schema.

Rows indexed by a partition key, with potentially millions of columns per row, optimized for huge time-series and append-heavy workloads.

The contract a database makes about what concurrent transactions can see of each other's work — from anything-goes to fully serializable.

Pessimistic locks the row before reading; optimistic checks for conflict at write time and retries on collision.

2PC offers strong consistency across services at a heavy cost; Saga gives you eventual consistency via compensating transactions.

Split data across machines by a chosen key — range, hash, geographic, or consistent hashing — to scale writes beyond one node.

Single-leader, multi-leader, or leaderless — each picks a different point on the consistency/availability/complexity spectrum.

B-tree for ordered range queries, hash for equality, GIN/GIST for full-text and arrays, BRIN for huge sorted tables — pick by query shape.

Normalize for write correctness and storage efficiency, denormalize for read performance — pick based on the read/write ratio.

A pool of pre-established DB connections shared by app workers — keeps connection counts bounded and reuses expensive TCP+auth handshakes.