This says that there is a poll duration: https://docs.xtdb.com/storage/jdbc/#_jdbc_as_a_transaction_log It would work for me but I'd like to know whether it accomplishes what I expect it to do.

Hey @U028ART884X 🙂 two nodes with identical config maps sharing a single JDBC backend (for tx-log and doc-store) will be eventually consistent replicas - both deterministically replaying and creating the ~same set of local indexes independently

> tldr: Would two XTDB instances sync their state if they both use the same PostgreSQL instance for storage? yes exactly, this is the key to achieving HA and horizontal scaling of reads

Thanks. Just tried to make sure. I wasn't thinking about this before but now I wanted to do something else with XTDB and I'm investigating. I think this is a good thing to add this to the webpage so that the people would see it easier :thinking_face:

Fundamentally it already is an event store, but those events are database operations not domain events. If you want to record domain events you have many options. For instance you could model the events using the entity history for a single entity, or you could use multiple entities with some sort of incrementing values under a common attribute (potentially :xt/id). You can certainly generate projections/aggregates manually and submit them into the database, but you could also draw inspiration from the xtdb-lucene module which uses the "secondary index" API if you want to leverage XT's existing checkpoint & replay machinery (note: that is quite an advanced level of usage).