6 ms·

What is Datomic, you ask? It's a database written in Clojure. https://hn.algolia.com/?q=datomic https://hn.algolia.com/?q=datomic Datomic is an operational d

What is Datomic, you ask? It's a database written in Clojure. https://hn.algolia.com/?q=datomic https://hn.algolia.com/?q=datomic Datomic is an operational database management system - designed for transactional, domain-specific data. It is not designed to be a data warehouse, nor a high-churn high-throughput system (such as a time-series database or log store). It is a good fit for systems that store valuable information of record, require developer and operational flexibility, need history and audit capabilities, and require read scalability. (via https://docs.datomic.com/pro/getting-started/brief-overview.html https://docs.datomic.com/pro/getting-started/brief-overview....)

mbesto 3y ago
For 90% of the web devs that just spin up Postgres/MySQL, why would you use Datomic over that?
- roguas 3y ago
  You have to add a lot of scaffolding to postgres to make it semi-immutable. datomic just is, wanna know previous user email, just go back and see. Out of the box, without thinking about it.
  - evantbyrne 3y ago
    Immutability is certainly tempting for certain kinds of data. Does it handle use-cases where data needs to be deleted though? i.e., privacy compliance.
    - mcbits 3y ago
      It looks like they call that excision, which leaves behind a breadcrumb saying something was deleted and which can't itself be deleted.
    - deleted 3y ago
      [deleted]
    - dgb23 3y ago
      Temporality in general becomes super handy if you have something like reports that need to be consistent across time. Or if you want to ask questions about the past. Or questions about the future without affecting the present.
  - mbesto 3y ago
    Super interesting, thanks.
- fulafel 3y ago
  A tangent but it would be interesting to see survey data of how many devs default reach for SQL first these days. A lot of people use various other kinds of DB models which are preceived to have smoother learning curves.
- deleted 3y ago
  [deleted]
- alecco 3y ago
  Just the temporal properties alone make it very useful for anything where it matters like billing, finance, inventory. Else you are in views/schema/indexing hell to do it on top of SQL. There is some SQL temporal support but it's not great and varies a lot. Also since it's not native to the storage it has a lot of complexity issues under the rug making it not great. Many financial systems use Event Sourcing (OOP + ORM). I had to suffer this at a previous employer. See https://vvvvalvalval.github.io/posts/2018-11-12-datomic-event-sourcing-without-the-hassle.html https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even...
  - slaymaker1907 3y ago
    The temporal support seems handy, but time is still going to be really tricky for financial systems. Datomic only covers what the physical state of the database was at a particular time, but there's also the effective legal time (maybe a payment was dated a day before the system actually processed it) as well as requirements to remove data after a period of time (including point in time stuff).
    - augustl 3y ago
      Indeed, it depends a lot on the domain. Datomic only has "technical" database time, and doesn't have any built-in way of modelling domain time. You can set the transaction timestamp manually when you write, but you can't set it to be earlier than the latest transaction that was committed. So, if you want your domain modelling to piggyback on Datomic time travelling, you can only do things like delaying writes for, say, an hour, and hope you have all the data by the time you commit to db.
    - nlitened 3y ago
      There's a bitemporal Datomic-like database from JUXT that does exactly that, I believe https://www.xtdb.com https://www.xtdb.com
  - riku_iki 3y ago
    > Just the temporal properties alone make it very useful for anything where it matters like billing, finance, inventory. you can easily create datamodel to have this in SQL dbs: create table transaction_history(..., execution_time timestamp);
- dgb23 3y ago
  That's not easy to answer. It's a question of: - mutable data vs immutable data - tables, row based vs tripple store, attribute based (EAV/RDF) - table schemas vs attribute schemas - relational connections vs graph connections - SQL vs datalog - nested queries vs flat queries and rules - remote access vs client side index etc.
- panick21_ 3y ago
  Because its a different model of integrating your database and your app. It allows you to write queries in a pull style, it can be trigger based, datalog or raw index access. Its by default immutable and allows historical query. It allows meta data on the transaction themselves. A lot of the time the user builds much of that himself or relays on frameworks to do it.
deleted 3y ago
[deleted]

mbesto 3y ago

For 90% of the web devs that just spin up Postgres/MySQL, why would you use Datomic over that?

roguas 3y ago
You have to add a lot of scaffolding to postgres to make it semi-immutable. datomic just is, wanna know previous user email, just go back and see. Out of the box, without thinking about it.
- evantbyrne 3y ago
  Immutability is certainly tempting for certain kinds of data. Does it handle use-cases where data needs to be deleted though? i.e., privacy compliance.
  - mcbits 3y ago
    It looks like they call that excision, which leaves behind a breadcrumb saying something was deleted and which can't itself be deleted.
  - deleted 3y ago
    [deleted]
  - dgb23 3y ago
    Temporality in general becomes super handy if you have something like reports that need to be consistent across time. Or if you want to ask questions about the past. Or questions about the future without affecting the present.
- mbesto 3y ago
  Super interesting, thanks.
fulafel 3y ago
A tangent but it would be interesting to see survey data of how many devs default reach for SQL first these days. A lot of people use various other kinds of DB models which are preceived to have smoother learning curves.
deleted 3y ago
[deleted]
alecco 3y ago
Just the temporal properties alone make it very useful for anything where it matters like billing, finance, inventory. Else you are in views/schema/indexing hell to do it on top of SQL. There is some SQL temporal support but it's not great and varies a lot. Also since it's not native to the storage it has a lot of complexity issues under the rug making it not great. Many financial systems use Event Sourcing (OOP + ORM). I had to suffer this at a previous employer. See https://vvvvalvalval.github.io/posts/2018-11-12-datomic-event-sourcing-without-the-hassle.html https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even...
- slaymaker1907 3y ago
  The temporal support seems handy, but time is still going to be really tricky for financial systems. Datomic only covers what the physical state of the database was at a particular time, but there's also the effective legal time (maybe a payment was dated a day before the system actually processed it) as well as requirements to remove data after a period of time (including point in time stuff).
  - augustl 3y ago
    Indeed, it depends a lot on the domain. Datomic only has "technical" database time, and doesn't have any built-in way of modelling domain time. You can set the transaction timestamp manually when you write, but you can't set it to be earlier than the latest transaction that was committed. So, if you want your domain modelling to piggyback on Datomic time travelling, you can only do things like delaying writes for, say, an hour, and hope you have all the data by the time you commit to db.
  - nlitened 3y ago
    There's a bitemporal Datomic-like database from JUXT that does exactly that, I believe https://www.xtdb.com https://www.xtdb.com
- riku_iki 3y ago
  > Just the temporal properties alone make it very useful for anything where it matters like billing, finance, inventory. you can easily create datamodel to have this in SQL dbs: create table transaction_history(..., execution_time timestamp);
dgb23 3y ago
That's not easy to answer. It's a question of: - mutable data vs immutable data - tables, row based vs tripple store, attribute based (EAV/RDF) - table schemas vs attribute schemas - relational connections vs graph connections - SQL vs datalog - nested queries vs flat queries and rules - remote access vs client side index etc.
panick21_ 3y ago
Because its a different model of integrating your database and your app. It allows you to write queries in a pull style, it can be trigger based, datalog or raw index access. Its by default immutable and allows historical query. It allows meta data on the transaction themselves. A lot of the time the user builds much of that himself or relays on frameworks to do it.

deleted 3y ago

[deleted]