I have never worked in an it operations where the skills of the developers was high enough to use eventsourcing - good on paper and for neckbeards - no junior can code up against it
Not my experience. We use event sourcing in production for enterprise level software and inexperienced developers have no problems using it after about 15 min of introduction. Just start with your bank account list of events as an example and build from there.
This can be useful for personal agents where you want to store memories or “thoughts” for one person’s life and work running on one machine to prevent drift or hallucinations… but the licensing does not make this feasible
Yes. Event Sourcing is a fantastic, natural fit for agentic workflows but because most current Event Sourcing DBs are deep into the enterprise, they are unwilling to OSS in fears of killing the cash cow.
As a result, there will be a lot of churn in the agentic workflows DB space, a few will gain traction using Event Sourcing and those will then generalize and become the OSS Event Sourcing offerings.
> While an EventQL precondition is evaluated, every other write waits, so that nothing can come in between; reads go on meanwhile. So that no write holds up the others for long, the EventQL preconditions of a write are evaluated for at most five seconds, all of them together, counted from when the write gets its turn: a write whose preconditions take longer is rejected, with nothing written, with a 400
That seems like a huge foot gun. Like, sure, you don't have to implement transactional semantics or think about consistency/MVCC/snapshots. But at the cost of "every UPDATE ... WHERE prevents every other write for up to 5 seconds"? Really?
That seems like a bad tradeoff, inferior to both (massive effort) implementing proper transactionality, (medium efffort, but significantly compatibility-breaking) removing support for hierarchically-nested subjects so that the global-mutex restrictions on UPDATE-WHERE can be lifted/efficiently scoped to a subject, or (lowest effort) removing support for EventQL preconditions entirely. In any sufficiently large/multi-developer system I don't imagine that "don't use EventQL preconditions" will effectively stick.
As it is, I feel like having the main event sourcing system blocked for up to 5sec on any one client's slow EventQL precondition is asking for pervasive downtime events out of nowhere.
That said, I may be missing something that ameliorates those issues! I'm just skimming docs, so take it with a grain of salt.
Not a user of this particular database, but in event sourcing you dont typically do updates like that? You just add events to the stream.
Is this not a lock per event stream? That would make a lot of sense and make the blocking not an issue as concurrent writes don't work well in that paradigm anyway.
> Since such writes are evaluated one after the other, writes that carry such a precondition more often than their query takes make every write wait longer and longer, up to five seconds for each of them ahead of it: keep them rare, or bound the query by event ID or by time where the rule you check allows it.
I guess having a generic precondition could be useful but in general for event sourcing systems the "lock" would usually just be to validate the current state and make sure that no other state was written since the current state was read.
I have never worked in an it operations where the skills of the developers was high enough to use eventsourcing - good on paper and for neckbeards - no junior can code up against it
Not my experience. We use event sourcing in production for enterprise level software and inexperienced developers have no problems using it after about 15 min of introduction. Just start with your bank account list of events as an example and build from there.
This can be useful for personal agents where you want to store memories or “thoughts” for one person’s life and work running on one machine to prevent drift or hallucinations… but the licensing does not make this feasible
> but the licensing does not make this feasible
Yes. Event Sourcing is a fantastic, natural fit for agentic workflows but because most current Event Sourcing DBs are deep into the enterprise, they are unwilling to OSS in fears of killing the cash cow.
As a result, there will be a lot of churn in the agentic workflows DB space, a few will gain traction using Event Sourcing and those will then generalize and become the OSS Event Sourcing offerings.
EventQL seems nice, but
> While an EventQL precondition is evaluated, every other write waits, so that nothing can come in between; reads go on meanwhile. So that no write holds up the others for long, the EventQL preconditions of a write are evaluated for at most five seconds, all of them together, counted from when the write gets its turn: a write whose preconditions take longer is rejected, with nothing written, with a 400
(From https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)
That seems like a huge foot gun. Like, sure, you don't have to implement transactional semantics or think about consistency/MVCC/snapshots. But at the cost of "every UPDATE ... WHERE prevents every other write for up to 5 seconds"? Really?
That seems like a bad tradeoff, inferior to both (massive effort) implementing proper transactionality, (medium efffort, but significantly compatibility-breaking) removing support for hierarchically-nested subjects so that the global-mutex restrictions on UPDATE-WHERE can be lifted/efficiently scoped to a subject, or (lowest effort) removing support for EventQL preconditions entirely. In any sufficiently large/multi-developer system I don't imagine that "don't use EventQL preconditions" will effectively stick.
As it is, I feel like having the main event sourcing system blocked for up to 5sec on any one client's slow EventQL precondition is asking for pervasive downtime events out of nowhere.
That said, I may be missing something that ameliorates those issues! I'm just skimming docs, so take it with a grain of salt.
Not a user of this particular database, but in event sourcing you dont typically do updates like that? You just add events to the stream.
Is this not a lock per event stream? That would make a lot of sense and make the blocking not an issue as concurrent writes don't work well in that paradigm anyway.
Yes it seems like the locks can be bounded:
> Since such writes are evaluated one after the other, writes that carry such a precondition more often than their query takes make every write wait longer and longer, up to five seconds for each of them ahead of it: keep them rare, or bound the query by event ID or by time where the rule you check allows it.
I guess having a generic precondition could be useful but in general for event sourcing systems the "lock" would usually just be to validate the current state and make sure that no other state was written since the current state was read.