It also seems like there's some demand to fund an open source version of Datomic:
https://news.ycombinator.com/item?id=13583620
Crowdfund open source Datomic alternative here:
Note that accumulate-only is a semantic property, and is
not the same as append-only, which is a structural
property describing how data is written. Datomic is not an
append-only system, and does not have the performance
characteristics associated with append-only systems.
What I've been thinking about about is step in the datomic direction, built on top of plain old postgres that wouldn't attempt full time travel, but would use the same general schema/model with history. It's seems crazy that in 2017 that we don't have a decent general option for most business apps to store facts that doesn't over-write the past as is done in current sql databases.
It's not clear just how much of a demand there is for an open source alternative to Datomic which I'm trying to measure with the sign up landing page.
PostgreSQL solution might work if there was a way to guarantee immutable audit trail. This is really why Datomic favored in financial industries as it gives a high level of confidence that the audit trail can't be manipulated (even if you delete a record, that action will show up in the audit trail).
I do agree that it's rather surprising that we still don't have something like Datomic on github with a liberal licensing like MIT or BSD.
It could be due to demand or high cost barrier associated with emulating something like Datomic. And this is what I hope crowdfunding will change the game. Pay people to work on their pet project full time by crowdfunding it.
This actually works pretty well, but I have a REST API fronting the whole setup - programs are not directly accessing the underlying table or views directly.
Have overheard of this in passing. Might elaborating on setup/use-case? Seems strange to me for someone to restrict themselves artifically and not expose the whole power of SQL etc..
Direct access to our HIPAA/IRB database instances are based on white-lists - most internal and all external teams are prohibited from direct database connections. So for those groups, there is no possibility of any SQL access to schemas.
We use API keys with a shared secret (like AWS) to sign REST requests. If internal and external groups need to work together to jointly CRUD some resources for a specific project, they can share an API key dedicated to that project.
There was also a push to switch from an app-centric view of data management to an API-driven approach serving hypermedia (collection+json). That worked conceptually, but most API users ignore the embedded hypermedia links. I find that too bad, as those links make generic API consumption clients much more resilient to change - following a link embedded in a response rather than relying on POST to a well-known URI is a useful abstraction.