A Brief Overview of Datomic

The foremost thing that sets Datomic apart is that it accumulates immutable facts over time. Most databases assign values into named locations such as a field in a particular row, a node in a particular document. In those systems, as those values change, the new values overwrite the older ones. Datomic tracks the entire history of a fact and allows you to access its previous states quickly and easily.

Datomic is a decomposed database. Datomic separates reading, writing, and storing your data into multiple interdependent components, each of which runs in a separate process. The components of a running Datomic installation will be some combination of:

• Storage services: the destination for persistent data. Examples are: DynamoDB, Oracle, file system, etc.
• Transactor: the process that controls inbound transactions, and coordinates persistence to the storage services
• Peers: processes containing your application code and the Datomic peer library, which can query the persisted data
• Peer Servers: special kinds of peers that can act as a centralized query server for clients
  • Clients: processes containing your application code and the Datomic client library, a lighter-weight engine that relies on one or more peer servers to perform the heavy lifting
• Console: a web server that provides a graphic interface for browsing and querying one or more Datomic databases

A running Datomic system consists of some or all of these processes running simultaneously. This decomposition means you can distribute reading and writing across multiple processes that do not conflict with each other. The lack of conflict between reading and writing processes provides horizontal read scalability.

The transactor process acts as a single authority for inbound transactions. A single transactor process allows the system to be ACID compliant and fully consistent.

Datomic leverages existing storage systems. This means that your data can be safely persisted in a known and trusted storage service, and you can migrate to alternative services in the future as your needs change.

There are two main models of developing with Datomic which you can choose between or integrate together: The Peer model and the Client model.

Both the Peer and Client model require that you run a Transactor, which is the central hub for inbound writes. The transactor is configured to know about your storage service, which is where indexes and values are persisted.

When you embed the Peer library in your application code, you are essentially adding your application code as part of the database system. Transactions are sent to the Transactor, and then to storage. All other Peer nodes are then notified of and sent the changes to the database. Queries or raw index access happen locally in-memory, dramatically reducing latency of reads.

The client library requires that one or more Peer Servers is running. Peer servers are special intermediate nodes that handle queries and caching. Peer servers can be scaled horizontally just like Peers. Clients have a network hop for read operations as the queries are sent to Peer Servers. The Client library is much lighter weight than the Peer library at the cost of increasing latency on reads.

Next, you can walk through a guide that explores the most common operations of a database:

• Get Datomic
• Connect to a database
• Define a schema
• Transact data
• Query data
• See the history of that data

To get started, Get Datomic

The Peer-based Getting Started tutorial can be found at Peer Getting Started.