A speaker described SQL databases as using event sourcing internally. That makes sense if the comparison is about replaying a write-ahead log during crash recovery, but it sounded like event streams might also be replayed while resolving ordinary queries, which I would not expect. Is that an accurate interpretation? How do transaction logs and event sourcing differ internally, and are there reliable resources for researching questions like this?
2 Answers
The statement was probably referring to a write-ahead log or transaction log, which is similar to event sourcing but not the same thing. In an event-sourced system, the event history is usually the source of truth and is retained so the current state can be rebuilt from it. In a typical SQL database, the tables are the primary source of truth, while the transaction log mainly exists to guarantee durability and support recovery. Log records may be discarded after they are no longer needed, so the entire database generally cannot be reconstructed from the remaining log alone. A query can sometimes read changes that have been logged but not yet written to their final table pages, but that does not mean the query is replaying an event stream. For example, a database may update a page in memory and record that page in its WAL; a subsequent read follows the table's data structures and reads the updated page from memory. WAL replay is primarily needed to rebuild state after a failure, not to answer every normal query.
Not necessarily. Event sourcing can solve particular problems, but SQL databases do not all use it as their internal storage model. It is better understood as one possible architectural approach rather than a universal database technique.
What kinds of problems is event sourcing useful for, and what would be a good way to investigate more specialized database questions like this?