Thank you. I knew that Datomic existed, and some of the basic things you pointed out here, but I'll take a closer look. It seems like you really think it has a

Thank you. I knew that Datomic existed, and some of the basic things you pointed out here, but I'll take a closer look. It seems like you really think it has a lot of promise. That being said, I don't think CRA is a panacea. Databases will always have a "read, decide what to do, write" pattern (because that is what happens in the real world, and databases model the real world). If the read happens at time T, and the write happens at time T+100; then you could have a race condition if something happens at time T+50. Postgres can detect such race conditions by using true serializability (based on a technique called Serializable Snapshot Isolation[1]). It gets tricky to apply the same technique for temporal databases, though I believe it's possible. Do you happen to know what techniques Datomic offers users to help avoid/detect/resolve race conditions? Don't get me wrong. I think it's a very useful direction to go in. I've done a lot of work on temporal features in postgres. I'm also aware of some of the limitations, however. You still need some kind of coordination and something resembling locks or a conflict detector. (By the way, please avoid derogatory comments about people who make different technology choices than you do. An argument could be made that postgres is CRA. And even if not, CRA versus CRUD is a small part of what is actually important to users; many of whom face a different set of trade-offs than you do.) [1] http://drkp.net/papers/ssi-vldb12.pdf http://drkp.net/papers/ssi-vldb12.pdf