it sounds like you want a datomic entity which may or may not have certain keys

not quite sure what a map to the attribute is referring to, but in Datomic that would more commonly be a ref to another entity instead of a serialized map

We want to have "dynamic" keys. So we did a ref to an entity that hold a "key" and a "value" and tried to use unique/identity on the "key" attribute + parent-id to get it to not create the same key twice for the same parent and override the value, but unique/identity doesn't do an upsert on a tuple type but just throws a unique constraint violation.

Possibly cardinality-many heterogenous tuple of key + value with insertions and deletions managed by transaction functions, and an entity predicate to ensure key uniqueness for good measure. If tuple is too limiting of value type, could use entities instead for each map entry

If amount of data is small and can be mostly opaque to datomic, consider just an edn/json string or nippy/fressian bytes type

Atomic merging can be implemented by transaction functions