前提是我还没有在生产中使用过原子，所以我想给你一个答案。

好处

1. 数据库查询功能强大(比非递归 SQL 更强大) ，而且表达能力很强。
2. 可以使用 Clojure 数据结构编写查询，并且它不像许多 SQL 库那样是一个弱 DSL，允许您使用数据结构进行查询。
3. 它是不可变的，所以你可以得到不可变性在 Clojure/其他语言中给你带来的好处 一。这还允许您在保存结构的同时，将所有过去的事实存储在数据库中ーー这对于审计等非常有用

缺点

1. 它可能比较慢，因为 Datalog 只是比等效的 SQL 慢(假设可以编写等效的 SQL 语句)。
2. 如果您正在编写大量的代码，那么您可能需要担心单个事务处理器会不堪重负。对于大多数情况来说，这似乎不太可能，但是需要考虑一下(您可以使用某种碎片，并且可能保存自己; 但是这不是一个用于存储股票点数数据的数据库)。
3. 启动和运行它有点棘手，而且它很昂贵，而且许可和价格使它很难使用托管实例: 你需要自己处理系统管理，而不是使用像 Heroku 上的 Postgres 或 MongoHQ 上的 Mongo 这样的东西

我确信我在每一方面都遗漏了一些，尽管我在缺点下面列出了3个，但是我认为在更多的情况下，缺点并不妨碍它的使用，这些优点会超过它们。价格可能是一个将阻止它被用于大多数小项目(你希望超过1年免费试用)。

为了获得更多的信息，请参考这个描述原子的 短杆。

表现力(比照数据目录)和不变性是令人敬畏的。在这方面，使用 Dataomics 非常有趣，只要稍微使用一下，就可以看出它的强大。

当考虑 Datom 是否适合您的应用程序时，一件重要的事情是考虑您将要存储和查询的数据的形状——因为 Datom 事实实际上非常类似于 RDF 三元组(+ 第一类时间概念) ，它使自己非常适合建模复杂的关系(链接图数据)——传统的 SQL 数据库常常会遇到麻烦。 我发现这个方面对我来说是最有吸引力和最重要的方面之一，它工作得非常好，即使这当然不是 Datom 独有的东西，因为还有许多其他高质量的图形数据库产品，当我们谈论基于 JVM 的解决方案时，必须提到 Neo4J。
关于原子模式，我认为它是灵活性和稳定性之间的正确平衡。

为了完成上面的回答，我想强调的是，不变性和记忆过去的能力并不是适合于一些特殊情况的“魔法特性”，比如审计。与“可变单元”数据库(目前占99% 的数据库)相比，这种方法有许多深层次的好处。Stuart Halloway 在这个视频中很好地演示了这一点: 阻抗不匹配是我们的错。

在我个人看来，这种方法从根本上讲在概念上更为理智。在使用了几个月之后，我并不认为达原子具有疯狂而复杂的魔法力量，而是一种更自然的范式，没有其他一些大问题。

下面是一些我认为有价值的 Datomic 特性，其中大部分都是通过不可变性实现的:

1. 因为阅读并不遥远，所以您不必设计您的查询，就像在线上探险一样。特别是，您可以将关注点分成几个查询(例如，查找作为查询输入的实体——回答关于这些实体的一些业务问题——获取相关数据以显示结果)
2. 模式是 非常灵活的，不需要牺牲查询能力
3. 将查询集成到应用程序编程语言中是很舒服的
4. 实体 API 为您带来了 ORM 的优秀部分
5. 查询语言是可编程的，并且具有用于抽象和重用的原语(规则、谓词、数据库函数)
6. 性能: 作者只阻碍其他作者，没有人阻碍读者。另外，大量的缓存。
7. 是的，还有一些超级大国，比如穿越到过去，推测性写作或者分支现实。

关于 没有何时使用 Datom，下面是我看到的当前限制和局限性:

1. 你必须在 JVM 上(也有一个 REST API，但是你失去了大部分的好处)
2. 不适合写规模，也不适合巨大的数据量
3. 不会特别集成到框架中，例如，您当前找不到一个从 Datomicschema 生成 CRUD REST 端点的库
4. 是个商业数据库
5. 由于读取发生在应用程序进程(“ Peer”)中，因此必须确保 Peer 有足够的内存来保存它在查询中遍历所需的所有数据。

所以我非常模糊和非正式的回答是 Datom 非常适合大多数非平凡的应用程序，这些应用程序的编写负载是合理的，并且您不会在许可证和 JVM 上遇到问题。

作为一个类比，对于 Git，您可以问自己同样的问题，与其他不基于不可变性的版本控制系统相比。

只是试探性地补充一下其他的答案:

可以公平地说，数据概念框架为可查询的数据存储提供了所有其他当前选项的更好选择，同时具有部分可伸缩性，并且性能不是特别好。

我说只有 只是一部分是可伸缩的，因为查询需要适合对等 RAM，否则就会失败。而且不是 非常特别性能，因为顶级的 SQL 引擎可以通过复杂的执行计划优化查询以适应内存，这一点我还没有看到作为数据组学中的一个特性提到过; Datomic 的事务和查询的分离可能在总体上抵消了这一特性。

不过，与许多 NoSQL 引擎不同的是，事务是一个第一类物件，在这个关键方面，它与 RDBMS 系统不相上下。

对于那些读取数据多于写入数据、需要事务处理、查询总是适合内存或内存非常便宜的应用程序，而且累积数据的总体规模不是 太大了，对于那些愿意接受 API 中隐含的新颖概念框架的用户来说，这可能是一场胜利。