Watch out for vectors: If they contain duplicates, or if order is significant, it won't be compatible with datomic's set-wise data model.

Watch out for types that are not supported by datomic: you will have to encode them into datomic somehow.

Watch out for cases where the key of a map entry does not determine the type and cardinality of its value

Watch out for nils: datomic does not support nil. This matters if you need to make a distinction between "I assert there is nothing" and "I do not assert either way".

In general: datomic is not an edn document store, but more like a graph database with schema on the edges (attributes) only. You do need to keep datomic in mind when planning the edn representation of your application data.

writing them down for later research, thanks! although you are making me think of the possibility of just starting with datomic directly and avoid all those gotchas 😉

Except for order, a datomic-first design will almost always be an easy and natural edn design

especially with spec, which encourages your keywords to be namespaced and have an unchanging type+cardinality on their value

but order is a complete PITA in datomic

noted, was aiming at saving edn files to disk from clojure data literals for prototyping but going to rethink it a little more