Frequently Asked Questions

Datomic is a general-purpose, ACID, datalog database that stores immutable facts (datoms) accumulating over time. This information model enables arbitrary horizontal read scaling and affinity for distributed architectures.

For more, see the Rationale and Overview.

All editions of Datomic are free of licensing fees. Datomic binaries are released under Apache 2.0 and available via Maven Central, with no signup required. With Datomic Cloud you pay AWS only for the infrastructure you provision; Datomic has no additional software cost.

Datomic is a good fit for systems of record that must explain themselves. It’s especially well suited to provide read scalability, audit capabilities, access to history, and developer and operational flexibility.

Examples of successful Datomic use cases include banking, transactional data, business, medical, scientific or financial records, and logistics and inventory management.

Datomic is not a good fit for applications that need unlimited write scalability or as storage for large, unstructured data (e.g. BLOBs or media files).

Datomic is consistent in both the CAP and ACID sense. Datomic transactions are always ACID. All transactions are serialized and all reads are guaranteed to be consistent. See the ACID docs and the Jepsen test report with its companion blog post.

Yes, Datomic is OS-agnostic. The only requirements are an application using one of the Datomic client libraries and HTTP access to the Datomic system.

No. The data in Datomic can be exported via datalog queries or direct index access to a file and format of your choice.

We intend to publish the specification for the Client wire protocol once it has been finalized. In an effort to prevent future breaking changes to the protocol, we are gathering information and user experience details prior to finalizing the specification.

Datomic comes in three editions:

Datomic is developed by Nu North America, Inc (formerly Cognitect).

Datomic development, product offerings, customer relationships and trade secrets remain independent from Nubank. Nu North America, Inc continues to offer professional services and support for Datomic customers. See the Contact page.

As Datomic’s patron, Nubank is well served by Datomic’s continued adoption at other companies. Datomic will continue to be developed as a commercially available, general-purpose database, rather than being restricted to internal use.

Unlike traditional RDBMSs, Datomic’s architecture separates storage, transactions, and query. Datomic’s data model is based upon a universal primitive relation, of datoms, rather than an arbitrary set of named relations. The query model, while relational, is based upon Datalog, not SQL. Datomic has weaker constraint capabilities than some RDBMS, but more flexible data modeling. It shares ACID transactions and arbitrary joins.

Most NoSQL databases sacrifice transactionality and join capability and adopt sharding and eventual consistency. They also often have data models not supported by relational logic. Datomic trades off arbitrary write scalability to retain arbitrary transactions and joins. It provides a strong data model and powerful query with arbitrary read and query scaling.

Datalog is a deductive query system combining a database of facts (the Datomic db) with a set of rules for deriving new facts from existing facts and other rules. This query capability is combined with a powerful hierarchical selection facility (pull), so you can recover tree-like data without joins or complex re-assembly. Datalog with negation is of equivalent power to relational algebra with recursion. Datalog is a great fit for application queries thanks to:

While there is no explicit limit, database performance will degrade beyond approximately 10 billion total datoms. Larger data sets can be split across multiple databases.

Enterprise support is available separately. Contact us at sales@cognitect.com if you require

A datom (pronounced like “datum”; plural “datoms”) is an atomic fact representing the addition or retraction of a relation between an entity, an attribute, a value, and a transaction.

A datom is expressed as a five-tuple:

Datoms are the fundamental building blocks of Datomic’s data model.

Datomic is a database of immutable facts (not places). While many queries might be interested in the 'current' facts, others might be interested in, e.g. what the product catalog looked like last month compared to this month. Incorporating time in data allows the past to be retained (or not), and supports point-in-time queries. Many real world systems have to retain all changes, and struggle mightily to efficiently provide the 'latest' view in a traditional database. This all happens automatically in Datomic.

A Datomic database is just a set of datoms, indexed in various ways. These indexes contain all of the data, not pointers to data (i.e. they are covering indexes). The storage service and caches are just a distribution network for the data segments of these indexes, all of which are immutable, and thus effectively and coherently cached.

The flexibility provided by Datomic’s simple data model empowers modeling many different data types naturally. The Universal Relation handles row-shaped, column-shaped, graph-like, and document-like data modeling equally well. Applications written to this model are free of the structural rigidity of relational and document models.

No. Datomic’s Universal Relation—where any entity can have any set of attributes—eliminates the need for tables. Queries can interrogate any set of entities without needing to resort to join tables or other mapping strategies.

Datomic supports a variety of scalar and collection datatypes. The Programming with Data and EDN docs provides details on all supported data types.

No. All databases have a schema, whether they are explicit (i.e. traditional relational databases) or inferred (i.e, so-called schema-less databases). Rigidity arises in systems to the extent that the schema pervades the storage representation or application access patterns, making changes to your tables or documents difficult.

The schema required to encode datoms is minimal, consisting primarily of the attribute definitions which specify name, type, and cardinality. The advantage of an explicit flexible schema definition is that it provides power to your system:

Datomic schema uses the same data model as application data itself — attributes are entities with associated attributes. Define schema by transacting attribute entity definitions. See the official schema documentation for examples.

Datomic’s flexible universal schema and multiple spanning indexes support row-oriented, column-oriented, document-oriented, key-value, and graph-like data modeling. See the Data Modeling section of the documentation for guidance.

Datomic provides several built-in mechanisms: ACID semantics, uniqueness constraints, schema value types, and functional (transaction) constraints. These features reject invalid transactions at the database level before they are committed.

Yes, Datomic includes a built-in transaction function :db.fn/cas for compare-and-swap (cas), enabling atomic conditional updates. See Built-In Transaction Functions for details.

Datomic automatically maintains a set of multiple covering indexes. These indexes each contain all of the datoms in the database, sorted in different orders, to provide efficient access to the data via multiple access patterns, including row-oriented, column-oriented, document-oriented, K/V, and graph. More information about Datomic’s indexes can be found in the Indexes docs.

No. Datomic’s built-in covering indexes are automatic, essential for efficient queries regardless of access pattern, and cannot be disabled or removed.

Datomic uses an efficient data representation (fressian), which is further compressed prior to storage. Given substantial decreases in storage costs, the Datomic design chooses to use slightly more storage space to provide a substantially more performant system.

Further, Datomic does not pay any penalty for sparse data: the absence of a given attribute on an entity does not require a null value.

The Datalog query engine automatically selects the most efficient index.

Some APIs like datoms, seek-datoms, or index-pull require an explicit index.

No. Unlike with sharding, Datomic data can be read and queried from any node. However, you can route requests so that groups develop hot caches for different workloads. This provides horizontal scaling without the compromises typically associated with sharding. In particular:

Yes, using Datomic queries:

Datomic uses Datalog, a logic-based query langage. Like SQL, Datalog is a declarative query language, meaning you specify what you want to know, but not how to find it. A Datalog system includes a database of facts (your Datomic database) and a set of rules.

The Datomic Query Engine takes a partially specified set of facts or rules and finds all instances of the specification implied by the database and rules. The Executing Queries page describes the fundamentals of buiding a Datomic Query.

Datomic represents transactions as data structures, not strings, making it easy to build requests programmatically.

The Processing Transactions section of the docs provides details on syntax and usage of Datomic transactions.

The mbrainz-importer library on GitHub serves as a reference implementation demonstrating practical patterns for importing existing data into Datomic.

The Examples page of the Datomic Documentation contains links to several example projects that use Datomic.

See the Get Started page for a guided tutorial, or the official documentation for comprehensive setup instructions.

The primary resource is the Datomic Documentation. For community support, see the Contact page — including the Datomic forum, Clojurians Slack, and the support ticket system.

We prefer not to discuss new features prior to their public release.

Datomic Cloud runs on Amazon EC2 and uses DynamoDB, Elastic File System (EFS), Simple Storage Service (S3), and several other AWS services.

Datomic Cloud is available in Supported Regions. Organizations interested in other regions for Datomic Cloud should contact Datomic directly.

Yes — Datomic Cloud can be deployed in any supported AWS region. Running it in the same region as your application optimizes latency and performance.

Datomic Cloud is built with many individual AWS services and relies on specific semantic and operational characteristics of these services. It is unlikely that an infrastructure-agnostic version of Datomic Cloud will be developed.

If you have a requirement to run somewhere other than AWS, Datomic Pro can be deployed anywhere.

Ions are functions that run in the same JVM as your Datomic Cloud system. They can contain arbitrary Clojure code, including using external AWS services. You will need to configure your Ions using AWS IAM policies to grant them the AWS permissions necessary for their specific uses of other AWS services.

There is no hard limit on the size of an individual Datomic database. However, running databases with a total history of more than 10 billion datoms may introduce a number of operational considerations. If your use case is likely to require more than 10 billion datoms, we would encourage you to contact us to discuss your system and optimize your deployment strategy.

There are no limits for reads. You can scale reads horizontally by

Writes to a single database are limited by the serial nature of Datomic transactions. This limit will typically only be encountered during bulk data import.

While there is no specific limit on the number of logical databases supported by a single Datomic Cloud system, each database requires some amount of memory and computational overhead on all instances in the primary compute group. A Datomic Cloud system should contain the database(s) for a specific purpose, and you should create separate systems for databases that serve separate purposes. The system planning documentation provides additional details to aid in overall system design and configuration.

Datomic Cloud handles scaling automatically. Datomic’s Scaling Topology will automatically add and remove EC2 instances from a Datomic cluster based on CPU utilization, within limits you control.

Moreover, you can start additional groups serving the same system, and route different tasks to different groups. For example, you might have separate groups for transactional load, analytics queries, and support.

Both Datomic Cloud and Datomic Pro support the same Client API, so applications are compatible with either. However, Datomic Cloud doesn’t support the Peer Library, and Datomic doesn’t provide a seamless process for moving databases between Cloud and Pro; see Moving To Cloud documentation for guidance.

You should NOT enable AWS Auto Scaling on the primary compute group. However, if you frequently write heavily to a larger number of databases than the number of instances in the compute group, you may wish to manually increase the overall size of the compute group to be equal to or slightly larger than the number of databases with significant write load.

The Scaling Topology distributes load across multiple compute instances. In the event of an instance failure, an Application Load Balancer (ALB) will remove the instance, distributing work to the remaining instances while a new instance spins up. Databases remain available throughout an instance failover, with incrementally degraded performance.

Datomic Cloud has no single points of failure, either of machines or of disks. Datomic Cloud uses AWS storage services that provide the strongest guarantees of throughput and fault tolerance:

Yes, in Datomic Cloud you can turn down your Auto Scaling Group to shut down compute or query groups without deleting any resources, reducing costs during periods of inactivity.

Datomic Cloud runs entirely within your AWS account in a single AWS region. Datomic will only provision AWS resources in the region in which you create your system.

No — Datomic uses a stratified storage stack, automatically leveraging redundant layers across S3, DynamoDB, EFS, local disk, and memory to deliver its semantic and operational guarantees and optimize reliability and performance.

Use Datomic Local to develop and test applications with minimal connectivity and setup. Specifically, divert-system enables development and testing of Datomic Cloud applications without connecting to a server and without changing your application code, making it suitable for local development and testing before deploying to production.

Consult the troubleshooting guide, which covers common problems accessing Datomic.

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the AWS cloud, where you can exercise complete control over aspects such as private IP address ranges, subnets, routing tables and network gateways. Datomic Cloud always runs in a VPC, so you can keep your backend isolated from the public internet.

Datomic is always accessed through an Application Load Balancer (ALB) that exposes only HTTPS.

You can control read and write access at the database level using IAM policies.

Datomic uses AWS best practices for securing data. Data is stored in highly-reliable services: DynamoDB and S3. Data is always encrypted using AES-256 at rest, and keys are managed via the AWS Key Management Service (KWS).

Yes. All Datomic data is encrypted at rest using keys managed by AWS KMS, addressing encryption requirements for regulated environments handling protected health information (PHI) and personally identifiable information (PII).

Datomic is free. Datomic Cloud has no Datomic license fee. You pay the AWS usage costs for the topology and instance types you run, as listed on the AWS Marketplace product page. Charges incurred for running Datomic Cloud are included in your monthly AWS bill.