Una cosa importante al considerar si Datomic es el ajuste correcto para su aplicación es pensar en la forma de los datos que va a almacenar y consultar - como los hechos Datomic son realmente muy similares a los triples RDF (+ noción de tiempo de primera clase) se presta muy bien para modelar relaciones complejas (datos de gráficos vinculados) - algo que a menudo es engorroso con las bases de datos SQL tradicionales. Me pareció que este aspecto era uno de los más atractivos e importantes para mí, funcionó muy bien, incluso si esto no es, por supuesto, algo exclusivo de Datomic, ya que hay muchas otras ofertas de alta calidad para bases de datos de gráficos, hay que mencionar Neo4J cuando estamos hablando de soluciones basadas en JVM.
En cuanto al esquema Datomic, creo que es el equilibrio correcto entre flexibilidad y estabilidad.

Para completar las respuestas anteriores, me gustaría enfatizar que la inmutabilidad y la capacidad de recordar el pasado no son 'características de magia' adecuadas para algunos casos especiales como la auditación. Es un enfoque que tiene varios beneficios profundos en comparación con las bases de datos de "células mutables" (que son el 99% de las bases de datos hoy en día). Stuart Halloway lo demuestra muy bien en este video: el Desajuste de Impedancia es nuestra culpa.

En mi opinión personal, este enfoque es fundamentalmente más cuerdo conceptualmente. Después de usarlo durante varios meses, no veo que Datomic tenga poderes mágicos sofisticados locos, más bien un paradigma más natural sin algunos de los grandes problemas que tienen los demás.

Aquí hay algunas características de Datomic que encuentro valiosas, la mayoría de las cuales están habilitadas por la inmutabilidad:

1. debido a que la lectura no es remota, no tiene que diseñar sus consultas como una expedición por cable. En particular, puede separar las preocupaciones en varias consultas (por ejemplo, encontrar el entidades que son la entrada a mi consulta-responder a alguna pregunta de negocios sobre estas entidades-obtener datos asociados para presentar el resultado)
2. el esquema es muy flexible, sin sacrificar la potencia de consulta
3. es cómodo tener sus consultas integradas en su lenguaje de programación de aplicaciones
4. la API de Entidad te trae las partes buenas de OR
5. el lenguaje de consulta es programable y tiene primitivas para la abstracción y reutilización (reglas, predicados, funciones de base de datos)
6. performance: los escritores impiden solo a otros escritores, y nadie impide a los lectores. Además, mucho almacenamiento en caché.
7. ... y sí, algunas superpotencias como viajar al pasado, escribir especulativas o ramificar la realidad.

Con respecto a cuándo no para usar Datomic, aquí están las restricciones y limitaciones actuales que veo:

1. tienes que estar en la JVM (también hay una API REST, pero pierdes la mayoría de los beneficios IMO)
2. no adecuado para escala de escritura, ni grandes volúmenes de datos
3. no estará especialmente integrado en frameworks, por ejemplo, actualmente no encontrará una biblioteca que genere endpoints de REST CRUD a partir de un esquema Datómico
4. es una base de datos comercial
5. dado que la lectura ocurre en el proceso de aplicación (el 'Peer'), debe asegurarse de que el Peer tenga suficiente memoria para contener todos los datos que necesita para atravesar en una consulta.

Así que mi respuesta muy vaga e informal sería que Datomic es una buena opción para la mayoría de las aplicaciones no triviales cuya carga de escritura es razonable y no tiene ningún problema con la licencia y estar en la JVM.

Como analogía, puede hacerse la misma pregunta para Git en comparación con otros sistemas de control de versiones que no se basan en la inmutabilidad.

Solo para agregar tentativamente sobre las otras respuestas:

Probablemente sea justo decir que datomic presenta el mejor marco conceptual para un almacén de datos consultable de todas las demás opciones actuales, mientras que es parcialmente escalable y no excepcionalmente eficiente.

Digo solo parcialmente escalable, porque las consultas deben caber en la RAM del par o fallar. Y no excepcionalmente de rendimiento, ya que los motores SQL de primera categoría pueden optimizar las consultas para que quepan en la memoria a través de planes de ejecución sofisticados, algo que aún no he visto mencionado como una característica en datomic; desacoplamiento de Datomic de transacciones y consultas podría en el offset general de esta característica.

Sin embargo, a diferencia de muchos motores NoSQL, las transacciones son un ciudadano de primera clase, lo que lo pone a la par con los sistemas RDBMS en ese aspecto clave.

Para aplicaciones donde los datos se leen más que se escriben, se necesitan transacciones, las consultas siempre caben en la memoria o la memoria es muy barata, y el tamaño de los datos acumulados no es demasiado grande, podría ser una victoria donde se pueda permitir un producto solo comercial, para aquellos que están dispuestos a adoptar su nuevo marco conceptual implícito en la API.