A database table, in the ordinary sense, holds current state. A row says a customer's address is this, right now. When the customer moves, the row is updated in place, and the old address is gone — not archived, not marked as superseded, simply overwritten. The table answers "what is true now" extremely well, because that is the only question it was built to answer. It cannot tell you what was true an hour ago, or how the current value was arrived at, because nothing in the table represents the sequence of changes that produced it. Only the destination survived the trip.
A log is the opposite commitment. Instead of storing the current value, it stores every change that ever happened, in the order it happened, and never removes an entry once written. Current state, if anyone needs it, is computed by replaying the log from the beginning — or from the last checkpoint — rather than stored as a thing in its own right. This sounds like a strange trade to make, and for a huge number of ordinary systems it would be: overwriting is cheaper to store, cheaper to query, and adequate for the question actually being asked. But four separate areas of computing arrived at the append-only log independently, for four different reasons, and it's worth looking at what each one was actually solving for, because the reasons don't overlap as much as the shared shape suggests.
Most production databases keep a write-ahead log, usually shortened to WAL. Before a change is applied to the actual data files on disk, it is first appended to this log, along with enough information to redo the change from scratch. Only after the log entry is safely written does the database go and modify the underlying pages. This looks backwards — why write the same information twice? — until you consider what happens if the machine loses power midway through updating a data page. A partially written page is corrupt; there is no way to tell, from the page alone, whether the write completed. But the log entry describing the intended change is a small, sequential, append-only write, and appends are far easier to make atomic than in-place modifications of a larger structure. On restart, the database reads the log from the last known-good checkpoint and replays every entry, redoing whatever didn't make it to disk before the crash. The log isn't kept for history's sake. It exists so that "what was I in the middle of doing" has an answer that survives the exact moment power was lost.
Event sourcing takes the same mechanism and promotes it from an internal recovery detail to the entire architecture. In a conventional application, the database holds current state and an audit table, if one exists at all, is a secondary, sometimes-neglected record of how that state changed. In an event-sourced system, the relationship is inverted: the sequence of events — "order placed", "item added", "payment received", "order shipped" — is the only thing actually stored durably. Current state, the thing a customer service screen displays, is a projection: a view computed by folding every event for that order into a running total, generated on demand or cached and rebuilt when the projection logic changes. If a bug in the projection code produces a wrong total for six months, event sourcing means the fix is not a data-repair script guessing at what the numbers should have been — it's a replay of the same events through corrected logic, which produces the state that should have existed all along. The event log doesn't just recover from a crash. It recovers from having been wrong about how to interpret the data, which a table that only stores current values structurally cannot do, because the inputs that produced the wrong value were never kept.
Streaming platforms generalize this again, for a different problem: getting many independent programs to agree on what happened and in what order, without requiring them to talk to each other directly. A producer appends records to a topic; any number of consumers read from that same append-only sequence, each tracking its own position independently, none of them able to alter what a previous record said. A new consumer, added months later, can start from the beginning of the log and derive exactly the same state every existing consumer already has, because the log is a complete, ordered, unmodified record of everything that happened — not a snapshot of where things currently stand, which would already have lost the sequence a new consumer needs in order to catch up correctly. The log here is doing a coordination job: it lets services that were never designed to know about each other agree on a shared, ordered history, purely by all reading from the same append-only place.
Blockchains push the same structure toward a fourth and different goal: making a rewrite of the past not just unusual but computationally expensive to pull off undetected. Each block includes a hash of the block before it, so altering an old entry changes that block's hash, which invalidates every hash chained after it, all the way to the present. Nothing stops a participant from hypothetically rewriting an old entry; what the chaining buys is that the rewrite is instantly and mechanically visible to anyone checking, because the chain of hashes simply stops matching. This is the same append-only shape as a write-ahead log, aimed at an adversary rather than a crash: durability against a machine failing versus durability against a participant who would prefer the record said something else.
It's worth being precise about what's shared and what isn't. A write-ahead log buys crash recovery. Event sourcing buys the ability to recompute state under corrected logic, and a genuine audit trail as a side effect. A streaming log buys coordination among readers who don't otherwise share a data store. A blockchain buys resistance to undetected retroactive editing. These are not four names for the same benefit — a system that only needs crash recovery gains nothing from blockchain-style hash chaining, and a system built for tamper evidence against a hostile participant is solving a much harder problem than a single trusted process recovering from its own crash. What they share is a structural bet: represent the sequence of changes rather than only the current value, and let current value be something you compute from that sequence rather than something you store as the primary fact. Four different problems, the same underlying move.
None of this is free, and it's worth naming the actual cost rather than treating append-only as an unambiguous upgrade. A log that never shrinks grows forever, so every real system built this way eventually needs compaction — periodically folding old entries into a snapshot and discarding (or archiving elsewhere) the entries that produced it, trading some of the "replay from anywhere" property for bounded storage. Querying current state by replaying an entire history is slow once the history is long, which is why event-sourced systems keep materialized projections rather than actually replaying from the first event on every read, and why databases checkpoint their write-ahead logs instead of replaying from the beginning of time after every restart. The append-only structure is usually not what a reader touches directly; it's the substrate underneath a faster, disposable, rebuildable view. The log is kept forever. The view is kept for convenience, and rebuilt whenever it turns out to be wrong.