The other day, I was talking to a Database Administrator about database fault tolerance and the different types of Transaction Logs. For reference in this article, a transaction log (also transaction journal or database log) keeps a history of actions (events) executed by a database management system used to guarantee ACID properties over crashes or hardware failures.
Databases store events internally to guarantee ACID properties. Does it mean a Database system implements an event driven architecture? The Short answer is no. And this is why.
This goes back to one of the greatest thought-provoking presentations from Martin Fowler about Event Sourcing. And understanding that Event-driven architectures are not the same as event sourcing.
Event driven architectures
The term Event driven architecture is used for any kind of software system which is based on components communicating mainly or exclusively through events. This software architecture paradigm promotes the production, detection, consumption of, and reaction to events. An event can be defined as “a significant change in state”. In the context of EDAs, the term “event” usually means “notification”. 
Event sourcing is a much more special term, referring to systems that store all changes to the application state as a sequence of events. A well-known popular class of examples are transactional database systems, which store any state changes in a transaction log. Here, the term “event” refers more to “state change”, not only to “notification”.
The state is persisted as a series of events in a place called the event store. New events get appended, but they don’t overwrite old events. As a result, all history is maintained.
Let’s contrast them in several areas:
Event sourcing is an alternative to traditional persistence strategies, with the purpose of keeping history. Event driven architecture is a distributed asynchronous architecture pattern used to produce highly scalable applications. In other words, event sourcing is about having historical records in an organisation, whereas EDAs are highly adaptable, scalable and can be used for small applications and as well as large, complex ones.
Event sourcing is usually applied in a single application/system, maybe implemented as services; however usually sharing the same storage. Meanwhile, EDAs are used across several apps/systems. Being a reliable integration pattern to achieve high levels of agility to respond quickly to a constantly changing environment.
Event sourcing has a central event store, which usually has replicas, sharding, etc. It relies on a central database. By contrast, EDAs are distributed so each component (or event processors) is decoupled and most likely to have their own storage.
Event sourcing is easier to test in comparison, since it can replay the whole sequence of events from scratch to arrive to a certain state/situation. On the other hand, EDAs are easy to test for each component in isolation, however testing the whole is complicated by the asynchronous nature of this pattern.
Comparing the 2 patterns offers clear evidence that we are talking about 2 completely different patterns. Both based on events, however with contrasting purposes, scope, and attributes.
-  Understanding Event-Driven Architectures (EDA): the paradigm of the future by Telmo Subira Rodriguez
-  Domain Events vs. Event Sourcing by Christian Stettler
-  Event driven architectures by Wikipedia
-  Event sourcing by Martin Fowler
-  Distributed data for microservices — event sourcing vs change data capture
This is a personal article. The opinions expressed here represent my own and not those of my employer.