A team proposes event sourcing for a product catalogue because "it gives us a free audit log and the ability to replay history." What would you actually push back on, and what does event sourcing cost that a normal row-plus-audit-table approach doesn't?

The audit-log benefit is real, but it's not free, and a product catalogue is close to the textbook case where it isn't worth the price: catalogue entries are current state that happens to change, not a domain where the history genuinely is the product (a ledger, an insurance claim). Event sourcing means the write model's state is never a row updated in place — it's the full sequence of events that produced it, replayed to reconstruct current state, which brings four costs that keep being paid for as long as the system runs, not once at build time. Events are forever: an old event type has to keep being replayable even after its shape has been renamed or restructured, which means versioning every event type and writing an upcaster for each old version, indefinitely. You can't query the event store directly — 'catalogue items added last month' is always a projection, never a query against raw events, which makes CQRS mandatory rather than optional. Deleting a single customer's data (a GDPR erasure request) against an append-only, immutable log can't be a DELETE statement; it needs crypto-shredding — encrypting each person's data with its own key and destroying the key — which is a whole system to build and operate. And the event store itself is new, specialized infrastructure. A plain row with an updated_at and a separate audit table written by the same transaction gives most of the audit benefit for a fraction of that operational weight, and CQRS with an outbox still gives you the read-model benefit on top of that, without needing event sourcing at all.