Datomic vs the O/R Impedance Mismatch

The root cause of complexity in today's database apps is the Object Relational Impedance Mismatch.
Object relational mapping (ORM) specifies how sets of java objects, including references between them, are mapped to rows and columns in database tables” (EJB3 251)
The OR impedance mismatch itself is caused by attempting to adapt mutable tabular data to mutable object graphs typically used in object oriented programming languages. Mutability is used in relational databases because we can efficiently update a record in place with a pointer write. However while mutable pointer writes make tabular data updates extremely fast, the consequence is that adapting these tables to an object graph is hard, with complicated and imperfect caching strategies in elastic configurations, and to maintain correct ACID properties, all reads (queries) must be performed by the database, because mutable data structures have no notion of time or audit of changes. All reads have to be done by the central authority or consistency is not guaranteed. Going over network to execute read queries in the central place (the database) is slow, necessitating the complicated and imperfect object mapper layers, a universally hated but necessary abstraction, hated essentially because it is not possible to have both ACID and local reads with mutable data. REST browser clients inherit all the same problems, except further magnified because the browser client is even further away from the central authority, the data access through more layers, and even more complicated and imperfect optimizations need to be hand coded at the web service layer to curb data access times down to a barely acceptable maximum. The industry is collectively starting to realize that this approach does not scale high enough, and we have seen various alternatives fail over the last decade (like NoSQL) because ACID is too important to give up.
Immutability offers a solution. Immutable data structures do not mutate in place, thus have built in versioning, because we can just save off old versions, and naturally encode a notion of time which can be rewinded in a way that is always consistent for a given value of time. The ability to guarantee a cache is consistent for a certain time value, means we do not have to traverse network to get a consistent answer to read queries. This is essentially how git works - git encodes time values as a hash - and why git is so much better than centralized source control systems of the past. So, an elastic JVM process can maintain a cache, consistent for some recent value of time, and confidently answer queries without going over network to the database. Similarly, a browser client can maintain a cache and fulfill data dependencies consistent to a value of time without going over network.
This is the key insight of Hyperfiddle, an experimental hypermedia app builder. The Hyperfiddle network is immutable and does not have an object relational impedance mismatch, same as Datomic.