No. You still need a regular database due to read performance. If I want to read the "latest" data, a search on an event store for a piece of data that wasn't changed in the past year would take an inordinate amount of time.

Additionally what if I want to look up a "row" of data that was modified 5 times on 5 different "columns" at various dates across 3 years? That's an aggregation job across 3 years of event data.

For event sourcing you still need to turn the "event" into an actual operation and record that database operation in a classic database.

Event stores just make the "event" the source of truth. It doesn't get rid of regular databases.

Traditionally other services read a single entity database/service and use that as a source a truth. Now a single button click records data across several databases and several services. It's not necessarily a better architecture, just different/buzz-wordy, and definitely more complicated.

Look up database as a value rich hickey talk on datomic which essentially does this.

Bottleknecks writes through an acid layer, makes reads against any single database connection (the value) immutable.

Querying history(values of attributes in time) is very very slow in datomic. It is meant for auditing/troubleshooting, not to be used for your application domain.

> For event sourcing you still need to turn the "event" into an actual operation and record that database operation in a classic database.

That's where the CQRS architecture comes into play. An event is recorded to the event store, the projection database is updated to the latest point in time, then any further reads are done from the projection database.