I put 7 years of meal data in Datomic - Here's what I learned - Christian Johansen

Datomic is an append-only database, designed from the ground up with modern applications and hardware in mind. It never loses data, it has an RDF-like approach to schemas, it's really fast, and it has a powerful query language borrowed from Prolog that expresses queries as data structures. In short: it's pretty awesome.
As both a geek and a food nerd, I combined two of my passions in a spare-time project where I put 7 years of meal plans into Datomic to build an application around the data. In this talk I'll take you through what using Datomic is like, show some examples from the app I built, and show you what kind of cool things you can do with a modern database.
If one database wasn't enough, I'll also show you Datascript, which takes Datomic's APIs to the browser (but can be used without Datomic as well). Forget about REST APIs to marshall data between server and client, with Datomic and Datascript, you can leverage generic replication to power real-time browser UIs.
NDC Conferences
ndcoslo.com
ndcconferences.com

[@mikl2345]

Great talk, one key point to note though - datomic creators suggest the term accumulate-only, not append-only, to describe datomic. The docs state "Datomic is not an append-only system, and does not have the performance characteristics associated with append-only systems". It does give you a lot more out-of-the-box leverage as a database, though...

[@mikl2345]

I'd be curious to know how Eventum faired regarding what is mentioned around 42:40 in the video. Specifically, the idea that datomic manages the time aspect of a domain for you. That seems to be a potential trap because the time aspect "managed for you" (via transaction time and hence history) cannot be updated later. That is, if domain time means to you time you can update, then the transaction time is not a place to store domain times. I'm not saying eventum got this wrong, they may well have understood it well, from what is on the video, but from reading around it is something that a few people have tripped up on when first encountering datomic so seems worth special care. Long story short, if you need times that you are going to want to change, you shouldn't think datomic's history feature will solve that for you with no effort. The history feature is only for when the database came to know about a fact, and to reflect that semantic, those times *cannot* be updated later (= the transaction log itself cannot be reordered). So it seems perhaps more helpful to think of the history feature as an extra thing that picks up where your modelling left off, rather than "managing (domain) time for you". So, so long this is fully understood, there isn't a problem. But for a casual user who expects the same freedom an update in place database gives (for those "timestamps" - they're not ordinary timestamps), it can come as a shock. A very sharp tool, study well before use! Full disclosure, I'm currently only two months into using & designing with datomic, so should not be considered an authority on this.

[@clickrush]

I agree. Datomic is by default unitemporal. To get bitemporality one needs to design their data to accomodate that, typically with a time period accociated with facts.