Compare
Side-by-side on the decisions that recur: index vs scan, normalize vs denormalize, optimistic vs pessimistic, partition vs shard, and more — with when to choose each.
Index Scan vs Sequential ScanNormalize vs DenormalizeOptimistic locking vs Pessimistic lockingRead Committed vs SerializablePartitioning vs ShardingRead replica vs ShardRelational vs DocumentPostgres + pgvector vs Dedicated vector DBCache-aside vs Write-throughB+ tree storage engine vs LSM tree storage engineHeap table + secondary indexes (PostgreSQL-style) vs Clustered primary index (InnoDB-style)LRU vs Clock (second chance)Synchronous replication vs Asynchronous replication
| Cache-aside | Write-through | |
|---|---|---|
| Who writes the cache | The app, on read miss; deletes on write | Every write goes through the cache |
| What gets cached | Only what is read | Everything written, read or not |
| Consistency | A window between write and invalidation | Read-after-write for cached rows |
| Write speed | Unaffected (delete is cheap) | Slower — cache + database synchronously |
| On cache failure | App still works (reads the DB) | Writes are impacted |
| Choose this when | The default: simple, resilient, caches only hot data — accept the invalidation discipline. | Read-after-write consistency matters and write volume is modest. |