Datomic Cloud
blog.datomic.com
blog.datomic.com
Jumping into AWS, at least in my work environment, is a big jump requiring lots of supporting infrastructure etc. We’ll get there if it works out, but the dockerized setup is really helping in learning and evaluation.
Officially supported ways of doing this is something i’m sure you’ve considered before, it would be nice if cognitect could reconsider this.
That said, we understand the value of a local development mode and that is possible in the future.
Now they are offering an approach where one can at least start at $1/day (Every time you scale out this goes up? What is the cost of support?).
The cheapest way to get started is probably still to run what is now called "on-prem AWS" (for up to 1 year), which there is already cloudformation for. https://docs.datomic.com/on-prem/aws.html
Would love to hear more about this.
You don't say to your girlfriend "We had fun the last three years, but probably I'm better off with my ex" unless you have no clue what you are looking for.
I'd love to hear your thoughts about how using Datomic in this immutable sense plays out in practice, because Rich Hickey's talk in favour of it is compelling. https://www.infoq.com/presentations/Datomic-Database-Value
Restrictions:
The Licensee hereby agrees, without the prior written consent of Cognitect, which may be withheld or conditioned at Cognitect’s sole discretion, it will not:... j) publicly display or communicate the results of internal performance testing or other benchmarking or performance evaluation of the Software;
This is a similar style I believe to the Oracle licensing model which used to prevent similar stuff I think.
Building your stuff on a platform (proprietary) with this attitude towards licensing... I'd say run away... fast.
For a relatively novel data model with potentially unusual performance characteristics, the chance of finding a properly done, fair, and generally understandable benchmark is virtually impossible.
See eg https://en.wikipedia.org/wiki/List_of_SPARQL_implementations
https://en.wikipedia.org/wiki/Datalog#Systems_implementing_D...
Also the various RDF things from the days of semantic web enthusiasm.
For active competitors, maybe the various GraphQL things and
As a small business, the choice seems to be pretty straightforward--pay multiple salaries to do PR, damage control, reputation management, etc. (and compete with huge corporations with deep pockets)...or pay those same salaries to engineers to build a better product for your customers, and get your customers to promise not to create PR headaches for you.
If something sucks, they will shout it to the skies. If it performs better or saves their ass on a key feature, they will shout it to the skies.
Let those shouts echo, and the equilibrium is how we decide on what's next.
Censorship is almost always a bad idea. Furthermore, you shouldn't chill the ability of people to talk about a platform if you eat your own dogfood and believe in it.
A license that prohibits a public benchmark is something only a few people care about.
Having seen hordes of developers on IRC, Reddit, and HN develop outdated gut reactions that they still invoke years after the fact has led me to believe that benchmark prohibition is easily worth it.
Might be like patents - being more of a defense mechanism, rather than an actual device intended to be used against customers.
!@#$ Oracle...
My advice is to develop with Datomic from the start and not separate it out into a service. Any other database will be so much faster that you won't know how bad your performance is until it's too late.
Another piece of advice would be to seriously consider if you need immutability in your database. If it's not a hard requirement, I would not use Datomic.
I don't know what your data team was doing, but they must have done it wrong.
My advice is to develop without a data team from the start ;)
Developing an application on top of ZODB vs on top of an SQL database leads to a very different data model design. You can't just swap one database layer out for the other and expect things to work well. I'm not surprised if a team who is used to developing on top of SQL-like DBs did not have good luck when moving to Datomic. It is just a very different model.
Then there is Datomics caching model in combination with its local data based query engine. The vast majority of critical queries only read from memory. Data that is fetched doesn't block other consumers.
So its specifically designed for such case where you need consistent transactional writes, while needing high scale reads.
Nice! Insanely fast? Awesome. What kind of queries compared to what databases?
> not appropriate for a system that has performance requirements
What kind of performance requirements?
Write performance, Query performance, latency? Other?
Where was the bottleneck?
I've found it's very hard for other databases to beat Datomic for query performance.
> Another piece of advice would be to seriously consider if you need immutability in your database.
Remember to check with your audit team, your reporting and analytics teams, your business users, and your data warehousing team.
This is an unreasonably simplistic approach to assessing performance. A useful approach would be to describe what workloads Datomic may or may not be suited for. Having used Datomic (On-Prem) 2 years in production, here's my take on it:
1. For a system that writes a lot (eventually leading to 10 billion datoms or having high peaks of write throughput), Datomic is not a great fit, because it has a single writer thread and does quite a bit of indexing. 2. Reads are horizontally scalable, and because Datomic's semantic allow for pervasive and reliable cacheing, reads can handle a huge load, and have low latency for OLTP-style queries. 3. Datalog is relatively slow for aggregations, and offers no facilities for trading accuracy for speed: if you need big, low-latency aggregations, you should offload it to a specialized store like ElasticSearch. This is especially easy to do with Datomic, because Datomic makes it trivial to implement change detection, in-real time if needed (see Log API and txReportQueue) 4. When writes are overwhelmed and become unavailable, reads stay available, which is an awesome situation to be in.
https://groups.google.com/forum/#!topic/datomic/gr9fscuF6oE
https://groups.google.com/forum/#!topic/datomic/NgVviV9Sw8g
It'd be swell if they put up a list of differences, because using the pull query API + clojure really is quite cool -- it's just good to know what you're getting into.
This clause was in-place and stood out to me as well. I had a chance to ask their legal team about it. The clause is written in legal-ese, which always sounds overbearing.
I asked the question in the positive sense, "what if have some really nice metrics from our use cases, and want to talk about them at a conference?" They simply asked to be consulted and request written permission to share. The intent, like others have noted, is to request (legally: insist) that Cognitect have a chance to review and point out potential implementation issues (good or bad) prior to customers making performance statements about their product.
The clause can/does put a damper on 'notes from the field' reports, which often help when deciding on tech direction.I look for community based reports to reinforce perceptions of a tool (to a degree). Completely agree with OP, do your own performance testing.
One thing I will say is that it would be hard for someone who hasn't invested in learning the inner-workings of Datomic's decoupled architecture to pick apart storage speed vs. transactor speed. For example, storage speed (SQL, DEV, Dynamo, etc.) is not a concern of Datomic, but a key dependency to measurable perf. This may change in the AWS service announced today, and become more uniform on dynamo and S3 "storage resources". https://docs.datomic.com/cloud/whatis/architecture.html#stor...
Datomic is a unique product and there are many ways to make it sing (or blow up) depending on how you use it. We designed data models, streaming processes, and queries with Datomic in mind and have had success. Exactly how much success, I'm not at liberty to say just yet.
I would have prefered a Datomic for Kubernetes to get this cross-platform and allow it to be hosted on different and private clouds because of my job I can not use AWS. I can't use Kubernetes either but there is at future possiblity that it would be possible.
The downside would probebly be that it would offer less integration as the ecosystem is not so far along as AWS. Still an easly containerised version for devlopment would be really nice.
Thanks to the Datomic team.
Seems the developer forums (https://forum.datomic.com/) are a good place to visit for practicalities after the web site.
Bitcoin is also definitely an open-source immutable database ;)
EDIT: Maybe not, wow.
Yeah, doesn't Bitcoin use BerkeleyDB underneath or something? Superficially it's immutable (when just API'ing to the blockchain) but underneath it's backed by BerkeleyDB I believe, which is your everyday mutable sql store
Maybe for querying read values of unspent transaction balances from blockchain ledgers, but the data integrity where it matters is on the chain where people can't screw with it...
There's also Mozilla's mentat and its predecessor atomish which talk to SQLite on the backend.
So, sorta?
[1]: https://github.com/cruzdb/zlog [0]: https://github.com/cruzdb/cruzdb
I really wanted to use datomic for a sideproject because what I wanted to do seemed to fit really neatly with the tuple and query language of datomic, other than datascript is there a db with a similar query language and way of having linked tuples?
The talk where I realized Rich is a data head too. Introducing his design goals and life experiences with db(s). https://www.infoq.com/presentations/The-Design-of-Datomic
"Clojure for the Brave and True" author, Dan Higginbotham, on key themes and overview. http://www.flyingmachinestudios.com/programming/datomic-for-...
Congrats to the Datomic team and Cognitect. I hope this move to cloud opens Datomic's design principals and ideas to a wider user base.
The Free Edition has limitations that impact how you would write code -- it supports only the "peer" API and not the "client" API, and is restricted in terms of backend storage choices and number of peers. So while it's very likely true there's perfect API compatibility when you want to step up to a paid edition, it makes you design to the artificial limitations they've used to set apart "free" from "paid".
Indeed, it's also not the recommended way to learn. The Datomic team says: "If you are trying Datomic for the first time, we recommend that you begin with a client library." In other words, the Free Edition doesn't include the client library that they recommend you try first.
If you step up to the Starter Edition you have full functionality and free updates but only for the first year. Beyond that, you start paying. Either you run in Cloud (as low as $1/day) or you purchase the on-prem Pro Edition ($5000/year).
Don't get me wrong. Cognitect has the right to charge whatever they like, and bundle features however they like. It's their intellectual property and they made the investment to create it.
But if you're building a hobby project then even $1/day may be more than you want to spend, and/or more than you want to impose on outside contributors to your codebase.
Even if this drives you to the $1/day edition, that should cover a lot of small projects. Especially as you don't have to keep it running 24/7 during development.
This makes it hard to select it for small projects because you know you'd have to pay the 5k or switch to something else if you ever wanted to scale.
1$ a day I think is still a bit high for a non-profit driven side project, but definitely an welcome improvement.
https://github.com/mozilla/mentat
See also this blog post for some background and history:
https://www.ncalexander.net/blog/2017/05/31/tofino-data-stor...
For some reason, that almost made me spit my drink. This looks cool, I'll check it out.
if you search online they did address this repeated request
in summary they do it for money, they dont know how to do it for money if its open-source, they already contributed clojure to the open source community
someone already was vocally aggressive about this in a blog: http://z.caudate.me/on-whose-authority/
and rich hickey didnt like it: https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...
--
My personal take on this its not that datomic is closed source or that it cost a lot of money
its that for its cost, its a valid option for fewer people
i use ms sql at work, and it cost a lot of money but .. you can easily make the business case for it
for datomic ... it would be much harder
datomic is a niche product .. which is not bad .. it is just where its at
Amazon or Heroku style.
Apple Acquires FoundationDB | https://news.ycombinator.com/item?id=9259986 (2015)
I poked around for a few minutes trying to find any assurances Datomic offers their customers should they be acquired, but couldn't even find the current EULA accessible online (older versions didn't seem to mention anything).
https://www.datomic.com/datomic-pro-edition-eula.html (https://web.archive.org/web/20160310175126/https://my.datomi...)
<Error><Code>AccessDenied</Code>To that effect I mostly credit the GNU licensing model. I know people love to hate it and praise BSD/Apache/MIT licensing but I believe without GNU, the proliferation would not have happened.
But back to the point, it is interesting that the expectation is reversed completely - people expect databases to be open source by default. Having said that, I still support author's decision to keep it closed source, it's their work and they intend to monetize it in a particular way. It's been around for years, presumably it works for them, which is great.
> seems pretty prescient given the glut of open source we find ourselves enjoying today.
Indeed, even regarding databases:
[from blog post] > Yes, there have been traditional demand-side efforts like MySQL and research efforts like PostgreSQL, but neither of these “good enough” efforts has actually been good enough to compete with Informix, Oracle,
Look at PostgreSQL today -- it's got a variety of indexing options, scalability improvements and various other things. It hasn't displaced Oracle but it's certainly not a research effort anymore.
Before I get into that part, forgive me, but I must admit that I've begun to tune out when I hear the "make Datomic open source" commentary. Still, this particular line of commentary returns from time to time, so I'll weigh in.
This reminds me of "meta stories" that take over the original story. On Hacker News, I'd much rather hear about technical commentary, lessons learned, or interesting domains and applications used in Datomic projects.
I tend to be less interested in hearing armchair quarterbacking around what business model would work better for Datomic, particularly when the arguments seem:
1. largely motivated by self-interest. Open source is often perceived as "free" to software developers. It is relatively easy to say "I would rather not pay for this software, why isn't this open source?" Of course, open source is not necessarily really free, due to integration and maintenance costs. In the cases where open source projects are abandoned, projects face substantial risk and transition costs.
2. not framed around the long-term interests of Datomic (at least the arguments rarely seem to make suggestions from the perspective of Cognitect, which invests in the product and makes income from sales)
It is easy to say "make it open source". It is harder for a company to find a business model that works. It seems that Datomic's business model is working. There is a free tier and paid tiers.
I know that I cannot properly summarize all perspectives with the ideal amount of nuance. Perhaps some people think it is really in Datomic's interest to be open source.
Nevertheless, it seems to me that many arguments people make are somewhat unexamined. Let's go a level deeper.
May I ask this: How many of Amazon Web Service's offerings are based on open source software?
I ask that question because there are four follow-up points I would like to make:
1. People use AWS quite extensively.
2. AWS is based on closed source software.
3. I don't think it is a coincidence that AWS is so successful.
4. It seems totally reasonable (and arguably the smartest thing to do) for Datomic to stay with a closed source model.
Also, I have no affiliation with Datomic, but I have used it on projects.
Just look at what happened to Parse. What if Datomic one day gets bought by some company that doesn't care about offering Datomic cloud or keeping it maintained? At least with Parse, people could migrate to an open source solution.
It is 100% understandable / practical / reasonable, yes. It is the same to recognize using Datomic technology as a core part of a technology stack involves some degree of additional risk, which grows as dependencies increase on its unique capabilities.
Agreed, and it is often tough to evaluate to any exact degree or measurement.
However, uniquely irreplaceable closed-source dependencies seem classifiable as carrying comparatively greater risk than thriving open source projects. This specific case is compounded because there are few (if any?) production-quality alternatives that offer what Datomic does, whether closed or open.
> What do you intend to take over maintenance of your database software if it is abandoned?
I would phrase this as "Can I hire a domain expert to fix blocking bugs in my database software if it is abandoned?", but this doesn't really account for the uniqueness of Datomic (unnecessary to really consider further since any fix is impossible due to being closed source).
It boils down to "is my business even possible if this disappears" evalutation considering Datomic a novelty that enables and/or dramatically simplifies very specific use cases (profitable even in the short term) that basically wouldn't be possible without it -- and I believe Datomic does this! The best marketing for Datomic would reveal these use cases, but they are often a competive advantage.
Yeah. Unlikely I'd be adding any additional real features or anything but why not? It isn't magic. I'd also expect a lot of other people doing the same and we can share the maintenance load.
There is also a lot of functionality that is obviously backed by very nice code a lot of people would like to see and potentially use other places. But knowing you can do necessary maintenance and tweaks, even if it is while you rewrite your whole db layer to work with another product rather than a permanent thing, is a serious benefit.
The reason I even bother to state the obvious in the case of Datomic is that having this 1 restricted area in the otherwise open ecosystem around Clojure makes me want to start looking for an alternative environment. I'm sure everyone else that says it feels similar and just hopes if enough people say it, it'll be opened up. Obviously, Clojure can be used without Datomic, but I can't help but feel like I'm missing out on the bigger vision by not using it and I don't like that feeling because that's exactly how vendor lock-in begins.
> "The regulation applies if the data controller (an organization that collects data from EU residents) or processor (an organization that processes data on behalf of data controller e.g. cloud service providers) or the data subject (person) is based in the EU."
https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
(However, this is off-topic for this submission specifically.)
It's really not clear to me how a company like datomic would cope with that in any practical way. Are they supposed to know what kind of data their clients store??
From a processor perspective, they have their own requirements/regulations: https://aws.amazon.com/blogs/security/aws-and-the-general-da...
See also: https://aws.amazon.com/compliance/eu-data-protection/
AWS/Datomic doesn't need to know what kind of data their customers store - it's up to the customer to be compliant with their part of GDPR.
I think it's on-topic for a database that (in my barely informed understanding) is famous for never deleting anything!
> "Excision is the complete removal of a set of datoms matching a predicate. Excision should be a very infrequent operation, and is designed to support the following two scenarios:"
> "- removing data for privacy reasons"
> "- removing data older than some domain-defined retention period"
> "Excision should never be used to correct erroneous data, and is unsuitable for that task as it does not restore any previous view of the facts. Consider using ordinary retraction to correct errors without removing history."
https://docs.datomic.com/on-prem/excision.html
I haven't read whether or not there's a difference here with respect to the cloud offering, as I wasn't able to find a corresponding Reference section in the cloud docs. However, given that :db/excise is a transaction operation, it's likely supported.
Edit to add: Looks like it currently isn't, see 'davidrupp below. That's important to keep in mind.
https://github.com/tonsky/datascript Datascript is also neat, it's an in-browser DB with datalog query syntax. There's some neat stuff possible with om.next + datascript: https://github.com/omcljs/om/wiki/DataScript-Integration-Tut...
Edit to add: And they have!