I think if you're aiming for any sort of broad adoption (are you?), then you'll have to add... SQL.
This may sound like heresy, but in practice the following line is going to be a showstopper for most people:
Peer.q("[:find ?entity :where [?entity :db/doc \"hello world\"]]", db);
I don't want to learn a new query language. And I'll most certainly not even try to re-train my team on it. Maybe
later I'll become curious about that fancy datalog-language to enable advanced features. But in the beginning, if you want my mindshare, you'd better spoon-feed me.
Take this lesson from cassandra. They started out with Thrift and an extremely cumbersome query-interface, which fit the cassandra data-model perfectly but not the brains of the developers.
Now recently they exposed their query-language as a SQL dialect, and suddenly cassandra is a joy to use.
You should do the same. It will be a lossy abstraction. You'll need weird, non-standard constructs to accommodate the peculiarities of your model. Purists will cry in horror.
BUT: It will look like SQL and roughly work like SQL. Everybody and their dog already knows SQL. People can jump in and bang out "select foo from bar ..." without thinking. People can re-use an entire galaxy of SQL-related tooling and knowledge that has evolved over decades. Most importantly: People can start with something they know and then adapt at their own pace to the great new things that your datastore enables.
Don't underestimate this if you're aiming for the mainstream.