Moving To Cloud
Datomic Cloud is ideal for greenfield projects where you need
- quick and easy access to Datomic on AWS
- more ops ability with less responsibility
- graduated pay-as-you-go pricing
In order to take greatest advantage of AWS features, Cloud uses a storage format different from that used in On-Prem.
We are currently designing migration tools for users who want to move from On-Prem to Cloud, but these tools are not part of the initial release. If, after reviewing the differences outlined below, you want to migrate from On-Prem to Cloud, we want to hear from you, and help you plan.
Similarities Between Cloud and On-Prem
The information model is what makes Datomic Datomic, and is entirely the same between Cloud and On-Prem. This includes
- datoms, entities, and indexes
- ACID transactions
- the universal schema
- Datalog query and structural pull
- the indelible, accumulate only model of time
- the database as a value
Difference 1: AWS Integration
Datomic Cloud is tightly integrated with AWS.
This has three implications:
- Greenfield Datomic apps on AWS should target Cloud
- Datomic apps that do not run on AWS must target On-Prem
- Existing Datomic apps on AWS can be ported to Cloud once the migration tools are available.
Difference 2: Clients and Peers
On-Prem supports client or peer access, while Cloud supports only client access.
This has two implications:
- Apps that target the client API are much easier to move between On-Prem and Cloud.
- Apps that make heavy use of peer locality will require substantial alteration for Cloud.
See Clients and Peers for more information.
In each of the areas in the table below, we believe that the Cloud architecture can offer capabilities that will be superior to those currently in On-Prem:
|tx fns, custom aggregates, filters||something better|
|user partition control||auto partitioning (now), partition routing|
|limited search capability||CloudSearch integration|
|byte array type||LOB types|
These and other differences are explained below.
Transaction Functions Etc.
In On-Prem, there are a number of capabilities that rely on code being ambiently available in the peer process, i.e. transaction functions, custom aggregates, and database filters.
In Cloud, these capabilities will be provided via mechanisms for dynamically adding your code to running cluster nodes. This capability is under active development, and we would love to hear about your use cases.
The peer model supports two kinds of tempids:
#db/id structures and
strings. The client model supports only strings. This makes client
drivers and client programs easier to write and use, and it eliminates
partition control as a user-space concern.
On-Prem provides a limited text search capability that depends on keeping two index types (Datomic and Lucene) roughly in sync, despite the fact that the two kinds of indexing have different Big O time complexity. On Cloud, we recommend using CloudSearch, and are considering adding CloudSearch integration as an option in Datomic.
No Symbol Magic
In an effort to transparently reach languages lacking a symbolic type,
On-Prem will in some situations magically convert strings into symbolic
types, e.g. ":hello" to
Cloud does not perform this kind of magic, and client libraries are always responsible for mapping edn types to sensible language-local representations.
Cloud does not currently support Excision.