So, it's based on the H2 Database Engine and noting in Datomic is inherently slow. The way it uses the database is that it pulls segments of data from the database, so you don't have a datom to row mapping or anything like that. You basically use the database as a key value store. 130,000 rows doesn't sound like a lot and a couple of hundred transactions an hour also seem small. I haven't done this myself but I don't think you will have any problems.

Okay, I'll give it a try. I know it's a small database, but I was worried because it's also the "dev" version. I could imagine a very naive dev version that just writes chunks of EDN to files and can only handle a free thousand datoms, or has to fully read into memory, or similar.

But it sounds like it's the other way around, and the dev version uses the capable though modest free version's embedded storage.

Yes, I know for a fact that it does! The storage layer is just insert or update of KV pairs that contains chunks of datoms for either log och index data.

Depending on the I/O subsystem of the box that is running the thing, it should be plenty capable. I have no direct experience with H2 but it probably performs well enough and it's not asked to do anything other than shuffling bytes back and forth. So, it's a quite ideal situation.

The real perf limitation is that the dev transactor process is also the storage process (it opens another port to serve peers’ sql queries)

I don’t know how well optimized that server code is

But I have used shared dev for light duty just fine; also as the target of large bulk import jobs just fine