It's first and foremost a document store / so for JSON or XML currently, that's why it's not SQL compliant. I think other query languages as JSONiq are much more tailored to this, albeit a niche of course (based on XQuery).
Regarding tamper proof audit logs not much is missing. Cryptographic hashes instead of XXH3, a commit hash chain and signed commits. Actually, I think that's a great addition with minimal changes needed.
What you can audit currently is "who changed what" for instance.
SQL was designed for tables and does this job indisputably well. However, even adding dots, lateral joins, and variants, it was not made for nested, heterogeneous data and reaches its limits with many levels of nestedness or high sparsity/extra fields (aka, denormalized data, aka semi-structured data).
The underlying constructs behind JSONiq and XQuery (which are 99% the same, differing only on the "JSON finish"), in particular the FLWOR expressions (which support pipe-syntax-like clauses natively), were designed in a W3C standardization working group by some of the same experts who also contributed to or edited SQL.
Besides, documents are split into fine granular nodes, so we have "no" upper limit besides running out of 48bit nodeKeys/node identifiers at some point maybe.
Furthermore, a (versioned, as always) path summary keeps track of all distinct paths, which is a key ingredient for the optional secondary indexes, which can index paths or paths and content among other stuff as simply indexing fields. Optionally you can also add indexes to speed up aggregate queries (which are basically column projections).
Furthermore, the whole storage can self-validate through checksums stored in parent pages up to the root as in ZFS for instance.
DeweyIDs can be optionally stored for each node, which can speed up the comparison of subtrees between revisions (in order to detect simply which changesets belong to a certain subtree without having to traverse ancestor chains). They lend themselves well for compression.
We even have importers which can identify based on heuristics minimal edit operations to import existing revisions of XML or JSON documents and to commit these with hopefully a minimal or close to minimal set of update operations, but it depends heavily on the data.
I'm working on a side-project in my spare time since the end of 2012 (before at the university) with some gaps, which is an append-only DBS with time travel capabilities using a custom storage engine based on COW tries and a (still I think) novel page versioning strategy called Sliding Snapshot. Recently I began work on pooling pages for reuse and a custom allocator for variable page sizes. Before, I had created new instances whenever a page was read from disk instead of reusing instances, so the allocation rate was really high for parallel transactions.
Don't be confused with JDK 23 EA, that doesn't mean it is coming on regular JDK 23 as preview, rather that is what the non-Valhala stuff is based on, as upstream.
I once implemented the backend of a calendar and resource control for a low code platform.
The control is highly customizable, with a lot of views to chose from, daily, monthly, yearly... but also resource views (you can book resources with custom groupings, by plugin, by the resource-ID, whatever...), define "plugins" on the data sources, what's the from- and to- columns, the title column, what's the resource (may be from a foreign key / 1:1 relationship or 1:N if it's from a "child" data source or from the same data source/table).
Furthermore I've implemented different appointment series, to chose from (monthly, weekly (which weekdays), daily...), which column values should be copied. Also appointment conflicts (or only conflicts if they book the same resource). You could also configure buffers before and after appointments where no other appointment can be.
That was a lot of fun and also challenge sometimes regarding time zones and summer/winter time in Europe and so on :-)
So, I think in my local bubble noone is for instance as excited about DB systems as I am, so in essence I thought I could even spend some money to get some expert opinions or rather insights I'm struggling with (currently for instance with bad throughput of my immutable OSS DBS). That said I think noone so far wanted money and some even offered help, but so far I think they didn't have time, thus didn't answer any "pings". So, as I can't spend too much time (and of course not too much money) either on profiling and debugging right now it's kind of a dilemma, as it would IMHO be very interesting to know what's slowing down N read-only trxs in my system :-) that said a couple of years ago I also asked about help with a frontend without much luck. I guess it has to have some value of course, so maybe at least spending some money (even if it's a non profit spare time project since 11 or even more years) should be OK :-)
That's understandable. The thing about asking others for help is that if it's something that will require more than a small amount of time or effort, then it has to be either a friend who is willing to sacrifice for you, or someone who is really into this stuff. The latter is more rare than the former.
You certainly can hire a contractor to help you out, but that's not going to be cheap. If you can afford the time, I think the best approach is to study up and achieve the level of expertise that you need for the task. You'll gain on two counts this way: you'll solve the issue at hand, and you'll have a new skill in your collection that you can leverage in other ways and on other projects.
Throughput. The code can be "suspended" on a blocking call (I/O, where the platform thread usually is wasted, as the CPU has nothing to do during this time). So, the platform thread can do other work in the meantime.
We're using a similar trie structure as the main document (node) index in SirixDB[1]. Lately, I got some inspiration for different page-sizes based on the ART and HAMT basically for the rightmost inner pages (as the node-IDs are generated by a simple sequence generator and thus also all inner pages (we call them IndirectPage) except for the rightmost are fully occupied (the tree height is adapted dynamically depending on the size of the stored data. Currently, always 1024 references are stored to indirect child pages, but I'll experiment with smaller sized, as the inner nodes are simply copied for each new revision, whereas the leaf pages storing the actual data are versioned themselfes with a novel sliding snapshot algorithm.
You can simply compute from a unique nodeId each data is assigned (64bit) the page and reference to traverse on each level in the trie through some bit shifting.
Regarding tamper proof audit logs not much is missing. Cryptographic hashes instead of XXH3, a commit hash chain and signed commits. Actually, I think that's a great addition with minimal changes needed.
What you can audit currently is "who changed what" for instance.