postgresql-event-sourcing
txid-syncing
postgresql-event-sourcing | txid-syncing | |
---|---|---|
4 | 1 | |
968 | 16 | |
- | - | |
5.3 | 4.9 | |
6 months ago | about 2 months ago | |
Java | Python | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
postgresql-event-sourcing
-
Hitchhiker's Guide to Moving from Relational Data to Events
This is an extremely well documented postgresql event sourcing reference implementation: https://github.com/eugene-khyst/postgresql-event-sourcing
-
Show HN: Light implementation of Event Sourcing using PostgreSQL as event store
Here is the code <https://github.com/eugene-khyst/postgresql-event-sourcing/bl...>
txid-syncing
-
Show HN: Light implementation of Event Sourcing using PostgreSQL as event store
Nice job, eugene-khyst. Looks very comprehensive from an initial skim.
I've worked on something in the same space, with a focus on reliable but flexible synchronization to many consumers, where logical replication gets impractical.
I have a mind to do a proper writeup, but at least there is code at https://github.com/cognitedata/txid-syncing (MIT-licensed) and a presentation at https://vimeo.com/747697698
The README mentions …
> A long-running transaction in the same database will effectively "pause" all event handlers.
… as the approach is based on the xmin-horizon.
My linked code works with involving the MVCC snapshot's xip_list as well, to avoid this gotcha.
Also, note that when doing a logical restore of a database, you're working with different physical txids, which complicates recovery. (So my approach relies on offsetting the txid and making sure the offset is properly maintained)
What are some alternatives?
ksqldb-event-souring - Kafka is not for event sourcing, isn't it? Kafka alone is not an event store, but Kafka and ksqlDB together allow building full-featured event stores. This repository provides a sample of event sourced system that uses Kafka and ksqlDB as event store.
sirix - SirixDB is an an embeddable, bitemporal, append-only database system and event store, storing immutable lightweight snapshots. It keeps the full history of each resource. Every commit stores a space-efficient snapshot through structural sharing. It is log-structured and never overwrites data. SirixDB uses a novel page-level versioning approach.
message-db - Microservice native message and event store for Postgres
Java-Spring-CRQS-Eventsourcing-Microservice - Java-Spring-CRQS-Eventsourcing-Microservice
eventstoredb-event-sourcing - EventStoreDB is the database for Event Sourcing. This repository provides a sample of event sourced system that uses EventStoreDB as event store.
emmett - Emmett - a Node.js library taking your event-driven applications back to the future!
Marten - .NET Transactional Document DB and Event Store on PostgreSQL
commanded - Use Commanded to build Elixir CQRS/ES applications
thalo - An Event Sourcing runtime with WebAssembly & embedded event store