When I started barakoCMS I told myself I'd keep it boring. A table for content, a table for users, some CRUD, ship it. That lasted about a week.
The thing that changed my mind was a support call, except it wasn't even for barakoCMS. It was an old client whose intern deleted a month of invoices during a "cleanup." We had a nightly backup, so we lost a day restoring to it and re-keying everything that happened after. Standard stuff. But I remember thinking: the database knew exactly what had happened. It just threw the history away the moment the row changed.
Event sourcing is the opposite deal. You don't store the current state of a thing. You store the events that got it there. A post was created, then edited, then published, then edited again. The current version is those events replayed in order. Nothing is overwritten. Nothing is silently gone.
I'm using Marten for this, which sits on top of Postgres. That mattered to me. I didn't want to run some exotic event store I'd have to explain to a future client. It's Postgres. You can open it with psql and poke around. Marten handles the append-only streams and builds read models (they call them projections) so the API still answers "give me this post" fast without replaying a thousand events every request.
The payoff shows up in places I didn't plan for. Version history came for free, because the versions are literally the events. Rollback is replaying up to an earlier point. When I added an audit trail later, half the work was already done, since the content changes were already events with timestamps and the user who caused them.
It's not all upside. Event sourcing makes you think harder about your projections, and there's a background daemon rebuilding read models that you have to actually operate. I hit a real one: a projection that crash-looped on boot because a migration created an index the wrong way. It passed every test, because every test environment already had the schema. It only broke on a genuinely empty database. Now I stand up a throwaway instance on an empty DB before anything real touches it, specifically to catch that kind of thing.
Would I reach for event sourcing on every project? No. For a CMS people are going to trust with content they can't afford to lose, where "what changed and who changed it" is a question that always eventually gets asked, it pays for itself.