Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> We are already using Clojure and I would love to introduce Datomic as well but being a commercial database makes it pretty difficult.

I don't see why paying for Datomic would be a problem, but if the license is as crazy as it used to be, that's a bit scary.

For example, the license at least used to forbid even saying "Datomic" aloud in public.

Publishing benchmarks was also forbidden, which is a big red flag. If Datomic performs well, wouldn't Cognitect want lots of benchmarks out there? If it doesn't, they wouldn't!

> I must say I often found the setup needlessly complicated. [..] No official way to set up of the whole stack with Docker or Kubernetes for example.

You don't find Kubernetes needlessly complicated? Do you actually need Docker or Kubernetes?



>You don't find Kubernetes needlessly complicated? Do you actually need Docker or Kubernetes?

They make life easier in my experience especially if you need something more than a simple self-enclosed application. For what I do we need Apache Spark, Airflow (which in turn uses RabbitMQ and Celery if you want to scale out), possibly JupyterHub (which also needs some way to spin up child servers), and then the application code itself.

I've wired some of it up myself in the past and it's a massive pain in the backside with lots of edge cases (Spark used to have a shitty massive python script for cloud deployments which always was missing something). Deploying it on Kubernetes with Docker on the other hand is rather simple. I basically trade the complexity of Kubernetes/Docker for the complexity of custom deployment/scaling/management code. In my experience, the code quality of the former is going to be much much higher than the code that an internal DevOps team outputs.


I've spent timing wiring up a similar setup with Airflow, and Celery on Kube, Kafka too, and running Spark clusters and echo the same sentiment. I also find Kubernetes easier/simpler compared to DC/OS, perhaps because it's a bit more structured and opinionated.


> I don't see why paying for Datomic would be a problem, but if the license is as crazy as it used to be, that's a bit scary.

Paying is not the only problem with using commercial tools, specially in the context of costumers and their own infrastructure.

> You don't find Kubernetes needlessly complicated? Do you actually need Docker or Kubernetes?

Kubernetes is complicated but what it does is very complex. Yes I do need it because if you have many costumers and many environments not using Kubernetes is 10x more complicated. That said we done require it but having it easily available would be very useful when considering using it in the company.

Having docker to run on the local machine is way preferable to other setups. I have not used a natively installed mysql or oracle db for testing in a long time. Given how tricky the setup for Datomic it would make things easier.


> For example, the license at least used to forbid even saying "Datomic" aloud in public.

> Publishing benchmarks was also forbidden

Seriously? I find this absurd, but I have no reason to think you aren't being accurate.

That is some corporate paranoia.


From the license https://www.datomic.com/datomic-pro-edition-eula.html

> The Licensee hereby agrees ... it will not: ... (j) publicly display or communicate the results of internal performance testing or other benchmarking or performance evaluation of the Software;


This kind of clause is usually known as a "DeWitt clause"[1], after a University of Wisconsin professor who benchmarked a couple databases, including Oracle (which performed poorly). Oracle/Larry Ellison didn't react well to that and decided to forbid benchmarks.

[1]: https://danluu.com/anon-benchmark/


Database performance depends on so many variables - thread pools, queue sizes, RAM allocations to different purposes, disk layout - the list goes on. There are whole consulting fields that are essentially doing a random walk through database configuration files looking for better performance - ascending the performance gradient if you will.

So in this world, its sensible to say "benchmarks are uninformative and misleading - your mileage will almost certainly vary"


Benchmarks are easily abused, misused, and misinterpreted. E.g., benchmarks looking at some very specific aspect of query performance being extrapolated to more complex/real-world queries.

Also trade-offs are rarely mentioned in benchmark numbers– e.g., great write throughput, at the expense of: ?.

It's fun to be cynical about stuff like this, but it's rarely as simple as "Ellison didn't react well to that and decided to forbid benchmarks".


> Oracle/Larry Ellison didn't react well to that and decided to forbid benchmarks.

So you kind of have to wonder why Cognitect is going Oracle on us..

The most obvious explanation is that Datomic just doesn't perform well and they don't want people to know.


Anyone who has done serious performance testing on a DB knows that there's a massive gap between initial findings and a well tuned system designed with the help of the database maintainers. I've seen some nasty performance out of Riak, Cassandra, SQL, ElasticSearch etc. But with each of those, once I talked to the DB owners and fully understood the limitations of the system it was possible to make massive gains in performance.

Databases are complex programs, and if I ever wrote one, it would be infuriating for someone to pick it up, assume it was "just like MySQL" and then write a blog post crapping on it because it failed to meet their expectations.


Yes, benchmarks can give a misleading impression of a database's performance.

So what? Somehow PostgreSQL is doing fine despite that.

Which is worse publicity for Cognitect: people publishing bad benchmarks or Cognitect forbidding benchmarks Oracle style?


Well, the absurd one was:

>the license at least used to forbid even saying "Datomic" aloud in public.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: