Unfortunately not, unless you follow a certain design pattern in your schemas. For instance, you can (and should) treat the txInstant associated with transactions as the dates at which Datomic learned of a fact, but never a domain time. Domain times should go into each of your database schemas instead.

Accounting is a classic example of this. In Datomic, you would want txInstants to represent when you’ve learned about the existence of e.g. some asset, but the domain time should represent when such asset actually existed. This can be kept in your schema (in the case of XTDB, you can explicitly set a valid-time when transacting the entity representing this asset). It practically gives you bitemporality, but valid times will not be first-class citizens like they are in XTDB.

In a running system it’s probably less important. I think it’s potentially more important when migrating already known facts.

Can you say more about your use case and domain?

^ use case & domain matter a lot. especially what features of datomic you see as most relevant. it’s useful to think of what bounds your transactional requirements. you can run w/multiple datomic dbs, so long as you don’t typically transact in ways where you have to coordinate across multiple dbs. time windows, regional splits, customer/tenancy, etc all could imply different sharding strategies for separate dbs (or partition strategies in pro to handle keeping queries on large dbs zippy). also what are your needs for accessing historical data? an on-going application request/response cycle for which as-of queries remain critical? or would way back as-of questions mostly see data warehouse or dev environment use? also do you ask substantive granular questions of everything that comes in the fire hose, or mostly just about extracted or aggregated info? it’s not uncommon for datomic systems to ingest only selections or transformations of data that’s being captured in the raw w/something like a high throughput event stream.

Without knowing more context, 10m facts/day also sounds like the type of data that a time series database is far better able to handle than Datomic

To answer your question about what constitutes a datom– you're correct, each update.

Hitting 10 billion datoms in 1000 days isn't unmanageable with any one of the sharding strategies Ben suggested. Regarding what happens– some of your fetches need to reach a little further down a tree the more datoms you have. My understanding is there isn't a real limit.

Really appreciate the responses. Yes, this is perhaps data that a time series database might handle better. For context, this is finance data for fixed income securities. Each day’s return can be split by risk factor. Each security could have up to 50 risk factor returns per day. Let’s say the total security universe is around 1 million (however, this could be bigger with more history). So, 5 million datoms per day.

I am making calculations (big map / reduce) over this data. However, some of the reduce components are dynamic (decisions are made by the user at query time). What is appealing about Datomic is the flexibility in the query language. Secondarily, features like as-of queries will be useful for deterministically understanding results that were run in the past.