Datomic Pro Starter Edition

Yes, same, I think a lot of people would be interested.

I've been working with Datomic, as a developer, in a production environment for the last 4-5 months. In terms of the work done by your ops guys, I'd say it really depends on how you're using it. Datomic has it's own AMI, which can be a hassle if you're used to rolling your own (which we ended up doing). I'd say one of the biggest challenges to overcome on the ops side is dealing with transactor failures. If a transactor dies, then the data from the peers will likely just fall on the floor. If you use DDB as a store, you have to keep an eye on your provisioning and scale appropriately.

Just to clarify, I don't know what problems sgrove ran into, I've asked him in IRC and will elaborate if he tells me, but at present, I dunno.

So here's what I have encountered:

Datomic's primary limitation is at the transactor level. Storage is a non-issue, especially if you're using DynamoDB. Even with PostgreSQL write-throughput was ridic because of the way they're using the database.

Transactor fail-over I'm not sure I'd take too seriously, but I don't think they'll drop any writes on the floor either.

You shouldn't attempt to run a datomic transactor on a cheapo VPS. Try to put together at least 4 gb of RAM. Which is the same as what's currently standard for consumer laptops. No excuses.

Deploying Datomic itself is straight-forward. The config is super simple and all you need as a dependency is Java. I'm actually a little puzzled that people want "Datomic as a Service". Datomic and PostgreSQL were the simplest parts of my stack to deploy.

You want beefy peers as well so as to make maximum use of the peer limitations on the license. This isn't as big of a deal as people think because you're not structuring your app the way Rails and Django apps do on Heroku. You don't do 1 beefy database + 5,000 terrible VPSes. Not only is that a management overhead (automation or not), but you're better off vertically scaling a couple peers first before running a shitload of dumb VPSes running your service.

The running assumption is that you should use DynamoDB, but PostgreSQL was seriously efficient for our purposes.

Indexing adds write overhead, but given the current limitations on what you can change in the schema online (nothing), you want to plan ahead here.

If you fail to anticipate something in your schema, you'll have to use a migration toolkit such as I plan to release soon.

The componentized nature of Datomic makes vertical scaling fairly pleasant as you can more precisely target what you're upgrading/improving.

You probably want to include a pass-through querying API in your peers accessing Datomic so that you don't have to run the REST service. This'll enable access to the data from a long-tail of servers that don't necessarily need to be that close to the data and are performing dumb queries. This solves the "but my webapp needs 100 crappy VPSes to perform!" problem.

Any kind of heavy-duty aggregation/analytical workloads against a Datomic dataset should be performed on a big peer with memcached. Use roll-ups for pete's sake! You can use a bi-temporal timeline with analytics data but I haven't fully explored the implications beyond Datomic making querying along that dimension nicer.

The Doc Brown array store presented at the Clojure meetup last night is a very interesting option for people doing multi-dimensional slicing of analytics data.

I'd personally use Datomic as a stand-in for any SQL database doing an OLTP workload, where previously I would've used PostgreSQL. Especially if history or reproducible results are important. That having been said, it appears to be adaptable to workloads I wouldn't have expected (analytics).

Super fast, better than any SQL database or MongoDB.

Datomic (free and pro) has an "in memory" version that I used when developing my Clojure application. Makes firing off test-cases super simple and nice.

I used fixtures (edn) for the schema and for example data as well.

I would reload/dump/interact with the in-memory database in my REPL directly. Quite nice.

You can run a test instance (free/dev, which uses H2), that's no big deal to setup either, same as running a local MongoDB or PostgreSQL instance. Ease-of-configuration is on par with MongoDB but with sane defaults. It "just works".

I use environment variables for configuration, so the default Datomic database is just an in-memory instance, but I can point it to a localhost free instance easily.

Whether I use a free instance or an in-memory instance depends on whether or not I need the full transaction log. Typically no, but the migration toolkit I'm working on requires a persistent database so the defaults there are different for testing/development.

I'm seriously in love with a database that has a embedded and "real world" modes of operation with parity in their functionality (except for the log).

Alright, that makes sense. Now it is interesting how the fact that you decided to forget would work. I guess if one always accesses the data via the official API and at the latest known state, that will work. But presumably the data will still be in stored in binary form in the back-end.

Another perhaps related question, does one have the option to "travel in time". Say I record that I forgot my mistakenly added passwords. But an attacker knows when that happens. Can they go back and inspect the data state right before the point when I forgot the data?

In theory sounds good but this is just not feasible.

Couple of scenarios:

1) A runaway data generator. Somehow you end up confusing milliseconds with seconds and now you start logging 1000x more data than you intended, you leave for the weekend and find your storage is full of junk

2) Sensitive data. Felix has just inserted all the passwords and credit card numbers in the database.

There's definitely a lot more to ACID than the part you mention, which fulfills the D or Durability aspect.

Though to any competent database engineer, they already know what ACID is.

The videos on datomic's website help clarify the understanding, but that isn't as accessible as well written text.

Thanks for breaking down the buzzwords into something understandable!

Generally speaking, five year olds should not be choosing databases for anything critical. But I agree that Datomic and company can do better with their marketing and general product description.

Here is one of the better explanations I have seen:

http://www.flyingmachinestudios.com/programming/datomic-for-...

Now this I understand. Thanks.

I'm self-taught at Relational Database Design. I spent two years worth of about all of my free time learning, and creating, large normalized SQL schemas. One of the things that most struck me was the capacity to get virtually all the advantages of a relational database without the baggage and rigidity. Add to that the fact that you have a distributed database with almost none of the baggage usually associated with such was another big thing for me.

Granted I'm coming from a do-it-myself green-field project, but the things that Datomic's structure and design opens up for my personal project mean that me, a one man show, can far more easily go toe to toe with the big guys with massive teams to design and deploy their apps and databases.

Potential is what I see, and it's far more than I've seen with just about any other technology that I can think of. I really think Datomic is a game changer, at least for the few awake enough to see it.

I haven't actually used Datomic yet, but what piques my interest isn't necessarily "ooh, Rich Hickey" as much as "ooh, the Clojure/functional approach to data immutability applied to a database". The appeal, to me at least, is in the potential to make my life easier as a product engineer, rather than as a DBA or devops guy.

See "Datomic: Can Simple be also Fast?"(https://news.ycombinator.com/item?id=6426362)

Why would I waste my time reading all of those articles or watching a screencast, if I don't have any idea what Datomic is? In order for me to be interested enough to click any of those links, I would have to think Datomic is a) interesting, b) relevant to me, or c) worth my time. The current website doesn't accomplish any of those objectives. That's what i'm getting at.

I'm sure it's a wonderful app, but its first-impression presentation doesn't tell me what it is I'm looking at. And as such, I'm just going to click away and find something else.

I guess where I'm getting lost is the terminology - I was under the impression that end-users are peers[0], so I'm worried about maxing out at two users. But if the limit is whatever a transactor can handle then I doubt I'd ever hit it and I might as well commit.

I'm looking at using it as part of a Clojure backend, if that matters.

[0] - http://docs.datomic.com/javadoc/datomic/Peer.html

edit: grammar