Query optimization is difficult because of the abstract structure and limited indexes. So you may query an index that holds EVERYTHING, and doing the query backwards would be faster... This'll depend purely on what you've inserted to the DB up to this point. Or more-so how you insert things into the DB.
Don't run an SQL server as your KV store you'll likely screw up the config and performance will suffer. If you want competitive performance with other DB's you will likely end up running memcache between your KV and Query Engine(s).
Don't store data over 1KB. Yes, the database can technically handle them, but in real world applications and expected speeds it can't.
B-Tree Syncs can be slower then you think in surprising number of cases.
I think Datomic is a very interesting project for a variety of reasons like use of Datalog, immutability etc.
This particular thing seems like a backwards step though. One of the major reasons why relational databases became so popular was that: the user didn't have to think about which predicate to put first in the where clause, or which join to do first. Query optimizers can do that much better, and there is decades of research on how to optimizer relational queries (including Datalog queries -- see Deductive Databases). It is hard for users to make such decisions, and complex queries, views, runtime parameters make it near impossible to reason about performance of different queries.
One thing to remember in high write environments: if you're storing a uuid attribute and it's indexed, use datomics squuid (sequential uuid). Rewriting the indexes will go MUCH faster and prevent latency spikes on queries.
I've been using it for years in production now. Hell, there was a strangeloop talk about our use of it. We're using Dynamo for storage.
I found working with Datomic really nice. I like how I can express queries using clojure. It also has some great performance for reads and the data cache cuts down on those reads from Dynamo, which keeps the AWS bill down.
I did not like the way schema worked in the beginning. You had to make sure you had it right from a very early stage of development and that can be difficult if requirements change, but they've addressed that in later versions. It's also probably the most complicated part of our infrastructure, which is 100% run on AWS. You've got 2 transactors (high availability) and X peers, you need to deploy a new version of Datomic on them. Coordinating that while minimizing downtime is no simple task.
Don't run an SQL server as your KV store you'll likely screw up the config and performance will suffer. If you want competitive performance with other DB's you will likely end up running memcache between your KV and Query Engine(s).
Don't store data over 1KB. Yes, the database can technically handle them, but in real world applications and expected speeds it can't.
B-Tree Syncs can be slower then you think in surprising number of cases.