Luis from Fauna here - confirming that we are working with partners like Grafbase, who can provide a fully featured GraphQL experience for use with Fauna. We are working with the Grafbase team to help them integrate with our new version of FQL and take advantage of the declarative schema support we have added to Fauna. Get in touch with us if you want to discuss more. -L
Sometimes the value is not in having a zillion configuration options with these providers but, instead, having a more accessible service that doesn't require a PhD.
And some of the people in those VC-funded groups were alumni of those providers too. :)
...but for distributed databases specifically, you can use a different algorithm like Calvin[0] or Fauna[1] that do not require external atomic clocks… but the CS point and the wealth of info in research papers (in distributed systems stuff) are solid
...but there is a lot of noise in those software papers, too - you are often disappointed by fine print, or have good curators/thought-leaders [2] - we all should share names ;)
enjoying the discussion though - very timely if you ask me.
I can attest to that statement: comparing Spanner and CockroachDB is difficult. Spanner and Fauna (where I work) are more comparable (Fauna is based on Calvin, see [0]) since they both support strict serializability (in different ways). The article referenced here is excellent, and it highlights what we've seen from some customers: CockroachDB is (to say the least) a challenge to learn and adequately deploy, I've seen a few others that have a similar lessons-learned result. I'm glad, however, that highly consistent distributed databases provide value in these implementations. Although not OSS, Fauna is comparable and more turnkey (read: much less ops) than these options.
If you are serious about transactionality, data consistency, and isolation levels, this sounds different from how you want to go. Both Firestore and Realm have shortcomings here. Fauna (where I work at, btw) and Surreal with FoundationDB on the backend, and Spanner are the only ones that can guarantee strict serializability in a distributed environment. I could argue that Fauna is the most turnkey (least pain to try, test, implement). With those "strict serializable" db's it is much easier to avoid data anomalies, as the ones mentioned in this thread.
As it turns out, other mature options offer this temporality out of the box. In Fauna (disclaimer: I work there) offers temporality out of the box so you can do a search on a record at a specific point in time in the past. It combines this with native JSON documents with flexible schema (so you can add additional notes as an audit trail) without disregarding relational modeling (it supports joins, foreign keys, normalization, etc.), and with low-latency distributed ACID writes nd transactions. A couple of other databases were mentioned here (Datomic and xtdb) that support this, and I believe it is just a matter of time where this will be more widely used. Two additional points to make: a) to the comment of "let's avoid RDBMS schema/migration hell by making everything a flexible JSON document" - that's a specific side effect of Mongo's design decision - since our db handles schema migrations quite elegantly, so I wouldn't be quick to assume that because Mongo did it that way that most systems will exhibit those side effects. b) The main reason I'm convinced this will be used a lot more (call it event-driven systems, temporal systems, etc) is because it will result in better-trained ML behavioral and prediction models too. So, might as well get ahead of this.
both good points, including the devs having different abilities and using a ready-made scalable solution. We're living in the world of having something working that you can test in a few days shrug
Fauna can do multi-region HA, across clouds, serverless, with transparent sharding and replication. We get plenty of people struggling with not being able to do low-latency, performant, strict serializability distributed writes. It is designed to be a turnkey hosted solution. https://dev.to/luiseduardocolon/fauna-deep-dive-architecting... - Luis
Yeah I think (heard anecdotally) both google/YouTube and Facebook (and many others) started with MySQL. Spanner for distributed writes has inspired most implementations although Google is the only one I know about that implements TrueTime (atomic clocks). The same year that the Spanner paper came out (after Percolator) an alternate approach (Calvin) was also published, and some of us are using that (our DB's design is inspired by it, but we've done a lot of enhancements since then).
My main takeaway from this article: as popular as Postgres and MySQL are, and understanding the legacy systems built for them, it will always require deep expertise and "black magic" to achieve enough performance and scale for hyper scale use cases. It justifies the (current) trend to have DB's built for distributed tx/writes/reads that you don't have to become a surgeon to scale. There are other DBs and DBaaS that, although not OSS, have solved this problem in a more cost-efficient way than having a team of surgeons.
Excellent point. Many discussions here do not emphasize transactional guarantees enough, and most developers writing front-ends should not have to worry about programming to address high write contention and concurrency to avoid data anomalies.
As an industry, we've progressed quite a bit from accepting data isolation level compromises like "eventual consistency" in NoSQL, cloud, and serverless databases. The database I work with (Fauna) implements a distributed transaction engine inspired by the Calvin consensus protocol that guarantees strictly serializable writes over disparate globally deployed replicas. Both Calvin and Spanner implement such guarantees (in significantly different ways) but Fauna is more of a turn-key, low Ops service.
Again, to disclaim, I work for Fauna, but we've proven that you can accomplish this without having to worry about managing clusters, replication, partitioning strategies, etc. In today's serverless world, spending time managing database clusters manually involves a lot of undifferentiated, costly heavy lifting. YMMV.
Good article, although the title might be a bit too click-bate-y... there's plenty of research and available services that reliably can have low-latency, distributed writes at the highest data isolation levels (strict serializability). Both the Calvin and Spanner papers describe such systems.
The two papers mentioned in the post are highly insightful. This is one of my favorite subjects.
To fully disclose, I have a biased view on this given that I work for a (closed source) serverless, no-ops DB provider (Fauna) that implements a distributed transaction engine that is natively document-relational and doesn't compromise on relational (ACID, transactional) guarantees.
This sounds like an interesting hybrid implementation, and I understand its motivation. However, if distributed writes at low latency with the highest consistency guarantees are essential, combining those two layers (Mongo and PostgreSQL) isn't worth the complexity. It looks like you can administer it with both Mongo and PostgreSQL tools, but do you want to? Clusters, partitioning, replication? That's a lot of heavy lifting.
To fully disclose, I have a biased view on this given that I work for a (closed source) serverless, no-ops DB provider (Fauna) that implements a distributed transaction engine that is natively document-relational and doesn't compromise on relational (ACID, transactional) guarantees. Although not directly comparable to an OSS DB, The market expects software and services to abstract as much complexity as possible. It is hard to imagine how such a Mongo/Postgres hybrid could handle hyper-scale apps that require highly consistent distributed writes.
There's definitely interest in both, but oftentimes for what I would argue are the wrong reasons. MySQL and PostgreSQL scale to a point but with complexity and data isolation limitations, but they will be always popular because of their longevity. Some NoSQL options scale better horizontally but the limitations of isolation levels are even more significant. Just because most of them now can handle ACID transactions and some form of joins does not mean they can handle strict serialization at scale. There are some, like Fauna, that do, however.
A lot of things have improved in distributed databases as of late. There are distributed databases today (my co. provides one) that can have strict serializability (the highest data integrity level) for hyper scale applications. Tolerating "eventual consistency" is largely a choice, oftentimes forced because your DB application or implementation (NoSQL and traditional RDBMS, depending on their implementation) does not provide you strict transaction guarantees. There are third parties (https://jepsen.io/analyses is a great source) that can evaluate and validate such claims. A lot of the anecdotal information in this thread here is no longer accurate or applicable. Yes, there are databases (like Fauna) that don't compromise on the highest transactional levels, and yes, there are more widely used databases (MongoDB, DynamoDB, and many others) that either cannot make those guarantees, or their implementation by their service provider cannot demonstrate that guarantee. Happy to provide more info if interested.
Understanding how serverless databases are architected, specifically databases like Fauna that leave the rigidity of traditional RDBMS behind without compromising or disclaiming correctness or consistency, will go a long ways to modernize data management practices as data continues to proliferate exponentially with the latest transactional, hybrid, and AI/ML use cases. As an industry, serverless provides for the delegation of operational complexity so we can focus on speeding up innovation on data insights discovery. Would love feedback on the paper, the blog article, and the subjects included in general. As someone that has endured database complexity ferom dBase to DB2 to MySQL, Postgres, and Mongo (to name a few), this is a conversation that is worth continuing. If there are places where it already happens, I’m eager to join in and contribute. - Luis