Insights after 11 years with Datomic [video]

Original Article ↗ Hacker News Discussion ↗

Adoption and Popularity

  • Many are surprised Datomic isn’t more widely used, given its design; others say the low adoption is understandable.
  • Commonly cited blockers:
    • Long history as proprietary, expensive software; now free “as in beer” but still closed source.
    • Tight association with Clojure and the JVM; non-JVM shops (Python/JS/Elixir) rarely consider it.
    • Lack of standard deployment ergonomics (no official Docker image, Cloud tied to AWS).
    • Difficult sell to management: critical data in a proprietary system from a small vendor.

Technical Strengths and Appeal

  • Immutability and append-only design make debugging, auditing, and time-travel queries much easier.
  • Full transaction log with rich metadata helps answer “what changed, when, and together with what else?”
  • Read scaling via peers running the query engine locally is seen as elegant.
  • Conceptually attractive to those comfortable with Datalog and functional programming; some call it “a marvel.”

Technical Pain Points

  • No query optimizer; query performance can vary massively based on clause ordering, which many see as a sharp edge.
  • Memory-heavy architecture (in-memory indexes on peers/transactor) raises scaling and cost concerns.
  • Datalog is unfamiliar; people already struggle with SQL, and writing queries as strings in Java feels clumsy.
  • Tooling gap: no pgwire/SQL compatibility, poor integration with common DB tools and ORMs.

Licensing, Ecosystem, and Strategy

  • Closed-source nature raises lock-in and longevity fears; “no Valkey move” if the steward changes direction.
  • Business strategy around Datomic Cloud + AWS and weak Java-first story are viewed as missteps.
  • Some argue the creators optimized for their own problems and expert users, not mainstream teams needing “easy.”

Comparisons and Alternatives

  • Many note you can approximate Datomic-style history with append-only tables, triggers, or event sourcing in Postgres/Oracle, though often with complexity/performance trade-offs.
  • Alternatives like XTDB, TerminusDB, temporal tables in MariaDB/Oracle, and custom event stores are discussed; temporal features are seen as valuable but often under-prioritized.