Depends on what you are after I guess. Datomic puts the query engine in your application, so you're querying over a built-in cache. This means Datomic could be rediculusly fast for often requested data (should always be in cache). Datomic allows you to "travel back in time" as it has built in time management. Writes never blocks reads. All writes are atomic. Datomic supports functions (Java or Clojure) in queries and transactions. There is more, but this was a list of my most liked features.

Of course, Datomic has some drawbacks as well. Like storage space. Datomic never deletes anything, and isn't exactly conservative on storage either. For instance, a timestamp is saved for every value in the database. This allows you to view the database the way it was at any point in time, or tell you exactly when a user changed his password, username or email, but it does have a storage cost. Since Datomic is distributed, you also need a bigger setup (more machines) than with traditional databases.

I know you're not contrasting against PG here, but just to add: writes never block reads in PG either, all writes are atomic, and you can create functions for use in queries.

The main USP for Datomic is the way it distributes data, which if you've got the right use case (i.e. you're generally querying over a subset of the data) is really nice.

Standard SQL also supports temporal databases: https://en.wikipedia.org/wiki/SQL:2011#Temporal_support

Datomic doesn't have an O/R impedance mismatch, which is a Really Big Deal.

I attempted to explain this here: http://www.dustingetz.com/2013/03/26/orm.html

'Better' is a loaded term, from what I gather it has functionality reminiscent of graph dbs and a temporal aspect to it (versioning / auditing).

> reminiscent of graph dbs

Why are you talking as if graph dbs are a thing of the past like the "object-oriented dbs"? I'm about to start a project for which a graph db seems the only sane option right now and I'm contemplating Neo4j vs Titan.

I see graph dbs as a the only sensible future because graph data is a very common type of data, and once your queries involve traversals, path findings with conditions and such, expressing them as joins becomes both a performance penalty and a need to basically implement a graph db atop a rdbms in a form of a monstrous graph-orm-thingy.

And once you use a graph db with acid and all the goodies, you'll probably ask yourself what's the point of having a two datastores system, so one will have to go away.

> expressing them as joins becomes both a performance penalty

Under the hood, graph databases are still effectively performing 'joins'. There'll likely be optimisations with respect to node lookups, but the fundamental issue of locality of access is still there: it's simply a hard problem in graph data storage. Depending on the flexibility/declaritiveness of the query language provided, there's still the issue of intermediate result set explosion that also plagues triple stores.

This isn't meant to say that graph databases aren't very useful: native graph stores will certainly offer some useful technical specialisations and ease of use benefits - it's more to say that there's not (afaik) anything wondrous under the hood that means that native graph databases fundamentally solve the performance challenges of graph-structures-on-relational-dbs.

I think you may have misinterpreted his use of "reminiscent"

That's exactly it - it's a triple store with an extra version timestamp column, which allows (partial) distributed caches to be brought up to particular timestamps. Writes then happen against a central transaction engine.