As I understant it:

Consider you have a database where you store the account balance.

If you want to update the account balance you might update the row for that customer, e.g.

tblAccounts ------------ | AccountHolderId | AccountBalance |

update tblAccounts set AccountBalance = @NewAccountBalance;

In an EventSource database instead you wouldn't update the AccountBalance column. You would store something like:

AccountEvents | AccountHolderId | AccountBalance + 100.00 | AccountHolderId | AccountBalance + 150.00 | AccountHolderId | AccountBalance - 80.00

Then ifyou wnat o get the current balance you can just take the opening balance and add 100, add 150 and subtract 80.

Periodically you need to collapse these as querying for the balance could end up requiring going through a large log of events. So you snapshot at some point in time. So assuming an opening balance of zero, we could snapshot the above to 170.00.

It feels like you get auditing / logging of all changes out of the box, also if you are working in functional programming or a system where you constrain side / mutability as much as possible you sort of eliminate your db as a giant mutable object. But you also get the downsides this article talked about.

Only store the events, and derive the current state by chronologically reducing the events.

That's all Event Sourcing is.

It's in the second paragraph. But I agree that it's a terrible name.

In a nutshell, instead of storing a current state of the data in a database, you store the "event", i.e. the information about the data being changed. You can also additionally save the current state, either at the time the event is saved or independently, but that simply acts like a cache when reading data; otherwise you would have to replay the whole events history to get to the latest state.

Just think of it as double-entry bookkeeping. It's been around for a while. :) The events that we record become our source of truth.