This sounds like a great, very valuable service. However, as far as I can tell, this service is not fundamentally different than running a MySQL server with replication. Nothing indicates it's "scalable" in the way that say, Cassandra, is. Replication is a perfectly adequate system for many people but it has its limits, especially for a write-heavy workload.
If FathomDB is more sophisticated than a highly managed MySQL-as-a-service I would be very curious to know.
That said, many of the complaints about scaling out MySQL stem from the painful management overhead of running a replicated setup, managing backups, etc. If FathomDB can vastly reduce the cost and difficulty of doing these things it may move MySQL a long ways towards addressing many of the reasons people are moving away from it.
"The end of NoSQL" is just another piece of claptrap that I've seen recently on this and related topics. I would agree that "AltDB" might be a better term simply because it's less inflammatory and better expresses the goals of many of the diverse projects now lumped under "NoSQL".
We need to work on our messaging! We're offering two different technologies: a fully managed MySQL as-a-service, and the new scalable database technology. But they're both relational databases in the service model.
With the MySQL-as-a-service 'traditional' tech, we take care of the backups, monitoring etc. We'll offer fully managed replication in future. As you say, these basic steps will make running MySQL much more attractive.
We've learned though, that there are still problems even here. You still have to think about how big your server should be. You still have to think about what happens when you outgrow the biggest server your cloud offers.
The new technology does scaling across machines in the same way that Cassandra promises, or that Oracle's Exadata does for relational DBs. It lets you start on a shared server and grow seamlessly to the point where you're running across multiple servers. But it's still early days for that tech (after all, lots of people still think it's impossible, despite the fact that Oracle is happily selling it!), and so we're not opening it up publicly yet, whereas the standard hosted MySQL is publicly available.
The new technology does scaling across machines in the same way that Cassandra promises, or that Oracle's Exadata does for relational DBs.
Care to elaborate a little bit more on your approach?
The claim you make (linear horizontal scalability) implies you have either created your own RDBMS or patched an existing one in a really exciting way.
I'm curious about how you managed in such a short time-frame what so far only Oracle can offer (with 20 years of experience under their belt)?
I'm also curious about when your new database offering will be available for public testing? Because currently the exorbitant claims make this smell a lot like vaporware...
We're looking for early-adopter customers with hair-on-fire problems with their database that would also make good reference customers in a few months. If you fit the bill, please contact me!
Otherwise, sorry, but you'll just have to wait :-)
To put the effort into perspective: it's not a new DB from scratch - that would be a Herculean effort - just the lowest levels. It's not based on MySQL/Drizzle; it's based on a different open-source DB with a friendlier license and more hackable code. It's a new technique for scaling cross machines, which is refreshingly simple, which is why you're not seeing too many details :-) It's not just Oracle that knows how to scale databases, BTW; Greenplum, Netezza, Vertica etc. have all built distributed databases (admittedly for OLAP workloads) in relatively short timeframes.
I'm quite interested in how you're handling joins in a manner that is scalable. What tradeoffs did you have to make? Do you support full join semantics, or are some types of joins not supported? Its not that much of a stretch to scale out an RDBMS not using any joins, but I can't bring myself to really take your claims seriously until you elaborate on how you handle joins (if at all).
I think that FathomDB's product is scalable to the degree that the existing database vendors are able to scale using multi-node clusters. Oracle's RAC tops out at 100 nodes. All of the other vendors (Teradata, Greenplum, etc) have some niche or secret sauce that allows them to scale vertical markets like OLAP. I don't see them scaling to Google or Facebook scale with an ACID-compliant relational database. They aren't really bringing anything new to the table other than a cheaper price point.
You bring up a very good point with the join issue. In addition, I'm wondering how they're going to scale writes. This is the bottleneck that eventually chokes RAC out, as it has to hold true to ACID principles. Even without ACID guarantees, eventually the system would spiral down into a chaotic quagmire of inconsistency as it scales. You've essentially got to have an locking and/or arbitration system that can quickly return an absolutely-positively we-wrote-this-in-a-consistent-way after a write query is executed. Nevermind trying to execute MVCC transactions over a cluster of nodes.
SQL can be scaled, ACID can't. Without ACID, the warm fuzzy feeling SQL gives you isn't quite as warm and fuzzy.
Well, you say that as if the difference between OLAP and OLTP was a minor thing. As far as I know OLAP is usually done on column stores with quite different properties to your regular MVCC RDBMS.
But well, I am not a database engineer. So, at least that was a response, thanks. I'll be looking forward to what you can deliver.
If FathomDB is more sophisticated than a highly managed MySQL-as-a-service I would be very curious to know.
That said, many of the complaints about scaling out MySQL stem from the painful management overhead of running a replicated setup, managing backups, etc. If FathomDB can vastly reduce the cost and difficulty of doing these things it may move MySQL a long ways towards addressing many of the reasons people are moving away from it.
"The end of NoSQL" is just another piece of claptrap that I've seen recently on this and related topics. I would agree that "AltDB" might be a better term simply because it's less inflammatory and better expresses the goals of many of the diverse projects now lumped under "NoSQL".