> 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.
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.
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.