heyo, any other jdbc+sqlite users out there? sometimes if there's an error or i interrupt the process the sqlite file gets and stays locked. curious if there's anything i could do to avoid that and if there's any workarounds

What is the scaling story of crux? Datomic has a single writer, but reads can be scaled horizontally. What is the similar statement for crux?

Reads scale horizontally also. Each node handles writes by itself, so you have a single writer limitation there too, effectively.

@dominicm That is, as long as you use kafka? Using rocksdb as backend will constrict you to one node, as rocksdb only supports one writer. Do I understand that right?

@sveri right. Rocksdb is not yet distributed (although I vaguely recall such a thing existing).

What about JDBC backend?

Would it be possible to have multiple tx_events tables in a database with JDBC?

The key thing to understand is that each node synchronizes with your event store. Your bottleneck is constrained by: - time to write to event storage - time to read event storage into indexes on each node

JDBC's speed at taking writes will be dictated by your underlying database & table. I don't know how the underlying table looks, but I bet a timescale hyperlog table would perform far better than a normal table. But you're essentially limited by your ability to append that table I think. I don't know much about the jdbc implementation. So take those guesses with a grain of salt and measure measure measure.

We currently only use JDBC for the golden stores - the transaction log and the document store (ie not for the query indices). Regarding the performance characteristics that we use for those - the transaction log adds rows to the end of a table, the document store is essentially a content-addressable kv-store

It'd be quite reasonable to mix-and-match those, too - Kafka for the transaction log (for its write characteristics) and JDBC for the document store

Each Crux node then consumes the transaction log and document store, and updates its own set of query indices - this is where RocksDB/LMDB shine

Is there any best practice when using Crux to implement a "global" counter, such as a human readable integer order number. One possible solution could be to have a document with the current value of the counter and then use a transaction-fn to read the value and add it to any new order, another could be to keep an index of orders in a document {:1 :internal-order-id-1 :2 :internal-order-id-2}, again updating and creating within a transaction-fn. What would be the trade-offs and am I missing any obvious solution?

Are there plans to implement something like :patch instead of only :put for crux? I imagine that the challenges can be incredibly hard, like patching a document with a future valid-time, but I also think it can be a killer feature :)

I think there's an implementation in user space, I asked about this recently and @taylor.jeremydavid answered 🙂

Thanks a lot for all the discussion! May I ask what is a query index? Is it the eavt/aevt/avet B-Tree?

@dominicm do you think it's possible to, like, transact a change in :age field with valid-time in the future with this userspace implementation, and it'll respect changes on other fields that happened before that valid-time?

Hi friends. We are considering firmly to adopt Crux as a persistent solution in places where we wold use a RDBMS or Datomic. It’d be nice to know about production use cases that can support this option.

The beta programme already finished or is still running?