Architecture trends are different than they were 25 years ago. Domain Driven Design has given way to Microservices and Event Streams, rather than large monolithic SQL Databases. There is a simpler way, but infrastructure needs to support it.
Most databases store information its current state. Event sourcing stores data as an append only log of events.
Read more at Use cases.
LiaraDB also provides a Key-Value storage system.
Isn't SQL capable of Event Sourcing? Yes, but it's complicated...
LiaraDB actually started out as a SQL based system, just like many other Event Sourcing solutions. It worked really well for storing data, but there was a catch. Replaying the entire log involves a race condition. If lots of Events are appended at once, the reader might skip some, and never return. There are some solutions, but none were ideal. Read more about it at Event Store SQL.
Going Event-native provided the opportunity to focus on one thing, and to do it well. Rather than supporting everything SQL does, LiaraDB optimizes for Event Sourcing.
Events that are appended at the same time are guaranteed to commit together.
In Event Sourcing, Aggregates are stored not as records, but as streams of Events. The current state of an Aggregate, is found by replaying events from the beginning. If the streams become long, we can store an image of the current state, so we can replay where we left off.
LiaraDB can be run on multiple servers to increase reliability, availability, and throughput.
Communication to the database, and between servers, is done via gRPC, a fast, secure, and modern protocol.