Here's the key, all the systems in which event sourcing works have clear immutable definitions of what an event does / means. eg. Git ALWAYS applies a commit i

Here's the key, all the systems in which event sourcing works have clear immutable definitions of what an event does / means. eg. Git ALWAYS applies a commit in a consistent way (and where it doesn't it's a disaster) eg. If you modify the transaction replay code from one version to the next of a DB, it creates a mess. (and why many databases won't replay transactions from previous versions, or even boot at all, see Postgres) The problem with event sourcing is that the same bad practices that came from the CRUD system are recreated using events, which makes the system inherently worse because now the state of your system is unstable, instead of just the manner in which you got to the current state. Imagine if everytime your rebooted your Postgresql cluster and it replayed Postgres 7 transaction logs, even though your running on Postgres 13, and generated an objectively different state, except, now your using CI and every commit from every developer will boot your system into a different state. Also, your database now takes 2 months to start as every transaction gets replayed. Take rails db migrations for example, the best practice is, every 6 months or so, to just dump the schema from production, create one large initial "migration" and add migrations from there, because eventually they become desynced, and you can't cleanly replay your migrations into a schema that mirrors prod. If you are extremely careful, and follow a bunch of best practices you can, but in the general case it costs less to just dump schemas.