Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.
Sign up to join this community
The idea of a database storing events and showing the net result of these events is realistic to the real world (and what actually happened).
Given the flexibility event sourcing databases offer (e.g. view the database at different points in time), why are such databases not more popular?
For example the only two databases I am aware of, that do event sourcing are Datomic and Event Store.
Arguably the write-ahead-log that pretty much every SQL (and many no-sql) product uses is an event stream, allowing rebuild of objects (tables) in the event an instance fault. Granted most of them are opaque binary formats unsuited for application interrogation.
For that the ANSI standard now defines temporal features for SQL. This records the interval during which a particular value was valid. Recreating history is a matter of including an "as of" date-time value in the predicate. There are products specifically for storing time series data efficiently at volume.
The net result of all change is exactly what each table/ document/ columnstore provides to applications.
To answer the actual question - the outcomes offered by CQRS stores are mostly available from other, better known and supported products. The business risk of adopting one may outweigh the functional advantages so the products are not widespread.
CQRS can be considered a design pattern as much as it can be considered a product. As such any mainstraim store could implement a CQRS.
Accounting, banking and finance systems in general will store full information about each transaction i.e. each state change. Think of your bank statement - it has a complete list of all the credits and debits which occured within the reporting period. Chances are your bank uses a relational database to achieve this. I know Xero uses SQL Server. It is a tenet of double entry book keeping (accountancy to you an me) that no change can happen to an account without a transaction (ie an "event") and every transaction, once recorded, is immutable.
