We now have a Windows build for dthk.exe and libdatahike.dll and https://github.com/replikativ/konserve-azure-blob, for folks who operate in this ecosystem. There is also finally a MacOS arm dthk release. The dthk tool now includes s3 backend support by default as well, so you can run datahike queries against a bucket in your system scripts.
I also landed writer fencing which is on by default now, and all konserve backends support a form of compare-and-swap (CAS), which means you can have concurrent writers safely by default. If you run Datahike embedded and can ensure a single writer is up then it is better to set it to exclusive instead, in this case it can auto batch and does not need to refetch on every transaction from the store.
This is documented here now https://github.com/replikativ/datahike/blob/main/doc/distributed.md#single-writer-model, lmk if things are unclear.
In the past the assumption was that you ensure that there is a single writer, but this can be tricky. @alekcz360 for instance pointed out that cloud services can spin up instances with overlap. This also happens in https://github.com/replikativ/datahike-serverless, which motivated this change as a better default for 1.0.
The shared writer support also allows to write web clients against S3 only, or use a file system folder and write from different processes with dthk. You need to be careful with NFS there though, some distributed filesystems don't provide proper locking/causality.
Currently I am still working on pg-datahike, which now covers a large set of Postgres' own regression tests, and has initial support for secondary indices like fulltext and pgvector through Datahike's secondary indices. This should harden our secondary index support and validate the design so we can get it ready, too. I also have to work on distributed GC for this, it might also turn out to include compaction for old trees or prior GC runs to avoid churn on the underlying storage and compact many small S3 blobs into larger directories. Once this is settled I think the secondary index support should become stable as well for 1.0. The final requirement I have currently is that I need async query engine support for https://simm.is. I thought I could postpone this, but it is important to make it flexible to fetch files for geschichte/git flexibly into the frontend and not preemptively push a lot of room and filesystem state into every browser.
And finally I spent almost two weeks getting our migration code into good shape (with feedback from @alekcz360): https://github.com/replikativ/datahike/blob/main/doc/migration.md, I would love to get feedback on this, including the Datomic support (experimental). It should be very straightforward now to take in and out larger than heap memory datasets and translate/filter them into Datahike databases.