FAQs

Encode the unique value in the ID (e.g. store the value(s) in a string ID, or use a map ID) of an entity representing that value, with a reference to the other entity that currently "owns" the value.

Use ::xt/match, however this takes time to confirm successful assertions and when there is contention you need to implement retry logic at each client.

Use a transaction function. This is slower still, though at least avoids the need to worry about contention & retrying. You can also express very complex constraints in these functions.

Declarative programming is ideal

SQL is the most popular declarative programming language but most SQL databases do not provide a consistent "basis" for running these declarative queries because they do not store and maintain views of historical data by default

Client-server considerations should not affect how queries are constructed

Recording history is valuable

All systems should clearly separate reaction and perception: a transactional component that accepts novelty and passes it to an indexer that integrates novelty into the indexed view of the world (reaction) + a query support component that accepts questions and uses the indexes to answer the questions quickly (perception)

Traditionally a database was a big complicated thing, it was a special thing, and you only had one. You would communicate to it with a foreign language, such as SQL strings. These are legacy design choices

Questions dominate in most applications, or in other words, most applications are read-oriented. Therefore arbitrary read-scalability is a more general problem to address than arbitrary write-scalability (if you need arbitrary write-scalability then you inevitably have to sacrifice system-wide transactions and consistent queries)

Using a cache for a database is not simple and should never be viewed an architectural necessity: "When does the cache get invalidated? It’s your problem!"

The relational model makes it challenging to record historical data for evolving domains and therefore SQL databases do not provide an adequate "information model"

Accreting "facts" over time provides a real information model and is also simpler than recording relations (composite facts) as seen in a typical relational database

RDF is an attempt to create a universal schema for information using [subject predicate object] triples as facts. However RDF triples are not sufficient because these facts do not have a temporal component (e.g. timestamp or transaction coordinate)

Perception does not require coordination and therefore queries should not affect concurrently executing transactions or cause resource contention (i.e. "stop the world")

"Reified process" (i.e. transaction metadata and temporal indexing) should enable efficient historical queries and make interactive auditing practical

Enabling the programmer to use the database "as a value" is dramatically less complex than working with typical databases in a client-server model and it very naturally aligns with functional programming: "The state of the database is a value defined by the set of facts in effect at a given moment in time."

Datomic maintains a global index which can be lazily retrieved by peers from shared "storage". Conversely, an XTDB node represents an isolated coupling of local storage and local indexing components together with the query engine. XTDB nodes are therefore fully independent asides from the shared transaction log and document log

Both systems rely on existing storage technologies for the primary storage of data. Datomic’s covering indexes are stored in a shared storage service with multiple back-end options. XTDB, when used with Kafka, uses basic Kafka topics as the primary distributed store for content and transaction logs.

Datomic peers lazily read from the global index and therefore automatically cache their dynamic working sets. XTDB does not use a global index and currently does not offer any node-level sharding either so each node must contain the full database. In other words, each XTDB node is like an unpartitioned replica of the entire database, except the nodes do not store the transaction log locally so there is no "master". XTDB may support manual node-level sharding in the future via simple configuration. One benefit of manual sharding is that both the size of the XTDB node on disk and the long-tail query latency will be more predictable

Datomic uses an explicit "transactor" component, whereas the role of the transactor in XTDB is fulfilled by a passive transaction log (e.g. a single-partition Kafka topic) where unconfirmed transactions are optimistically appended, and therefore a transaction in XTDB is not confirmed until a node reads from the transaction log and confirms it locally

Datomic’s transactions and transaction functions are processed via a centralised transactor which can be configured for High-Availability using standby transactors. Centralised execution of transaction functions is effectively an optimisation that is useful for managing contention whilst minimising external complexity, and the trade-off is that the use of transaction functions will ultimately impact the serialised transaction throughput of the entire system. Within XTDB, transaction functions are installed via put operations and all invocation arguments are stored separately in the document store. Once invoked as an operation, a transaction function has access to a context against which you can run a query, and this is how you can update a counter based on its current value. The result of invoking a transaction function is a list of one or more operations which are spliced into the transaction to replace the calling operation. Nodes which are subsequently indexing the transaction log will not have to repeat this processing of the transaction function operations because the argument documents (to which the transaction log refers under-the-hood) are idempotently mutated and replaced with the resulting native operations. In other words, each transaction function invocation replaces itself with its result in the upstream document store, and this maintains consistency whilst not precluding later eviction operations on the data generated within the results.

Datomic’s datom model provides a very granular and comprehensive interface for expressing novelty through the assertion and retraction of facts. XTDB instead uses documents (i.e. schemaless EDN maps) which are atomically ingested and processed as groups of facts that correspond to top-level fields with each document. This design choice simplifies bitemporal indexing (i.e. the use of valid time + transaction time coordinates) whilst satisfying typical requirements and improving the ergonomics of integration with other document-oriented systems. Additionally, the ordering of fields using the same key in a document is naturally preserved and can be readily retrieved, whereas Datomic requires explicit modelling of order for cardinality-many attributes. The main downside of XTDB’s document model is that re-transacting entire documents to update a single field can be considered inefficient, but this could be mitigated using lower-level compression techniques and content-addressable storage. Retractions in XTDB are implicit and deleted documents are simply replaced with empty documents

Datomic enforces a simple information schema for attributes including explicit reference types and cardinality constraints. XTDB is schemaless as we believe that schema should be optional and be implemented as higher level "decorators" using a spectrum of schema-on-read and/or schema-on write designs. Since XTDB does not track any reference types for attributes, Datalog queries simply attempt to evaluate and navigate attributes as reference types during execution

Datomic’s Datalog query language is more featureful and has more built-in operations than XTDB’s equivalent, however XTDB also returns results lazily and can spill to disk when sorting large result sets. Both systems provide powerful graph query possibilities