5 ms·
It seems like one of the big issues with the marketing copy here is some of the word tricks being played: Any first-read of "The first serverless database" has
by akerl_ 10y ago
It seems like one of the big issues with the marketing copy here is some of the word tricks being played:
Any first-read of "The first serverless database" has the implication that the database is serverless. Comments from FaunaDB folks in this comment page clearly indicate that they mean is that it's the first database for serverless, which is a pretty bold claim, given Google and AWS and any number of other providers offer databases that are accessible from serverless things, so it essentially boils down to "The first database that's marketed specifically to serverless use cases", which is maybe true but also kindof not a useful trophy to put on the mantle?
This is further muddled by the blog post linked to from the launch announcement (https://fauna.com/blog/escape-the-cloud-database-trap-with-serverless https://fauna.com/blog/escape-the-cloud-database-trap-with-s...), which includes "FaunaDB Serverless Cloud is an adaptive, serverless database". Nobody is reading that and thinking "ah, an adaptive database for serverless apps".
To describe it as "The first active-active multi-cloud database", is possibly true if you mean "the first time a single company has sold a publicly-available database-as-a-service running on multiple cloud providers". But the text says "database" where "public database-as-a-service" would be the accurate term, leaving the reader with the impression that no existing databases can be set up on multiple cloud providers in an active-active HA config, which is absurd. Fixing the copy here should be pretty easy, and they're already headed in the right direction with the next bullet point, although it as well refers to "database" where it means "database-as-a-service".
It feels like somebody on marketing really wanted to have a list of firsts, so they toyed with definitions of words until they thought they could flex these into being technically accurate. I get the same feel from the closing argument in the linked blog post: "The query language, data model (including graphs and change feeds), security features, strong consistency, scalability and performance are best in class. There is no downside.". I don't think I want to trust a database if the folks designing it couldn't think of any downsides.
- evanweaver 10y agoUnderstand. We can be careful to be more accurate even in less technical contexts in the future. Serverless is supposed to mean: a database with serverless pricing, for serverless applications. There's always a tension, too, between "does a feature exist somewhere" and "is it actually usable?". For example, you could perhaps run MySQL Cluster across multiple public clouds...but would you want to? It's surprisingly hard to design for true cross-continent global replication, and the additional latency of crossing public clouds makes it even worse. We've tried to design the best database. We can put in some bugs for you to give it some downsides.
- akerl_ 10y agoI'm not talking about bugs, though I promise there are some. No offense intended by that: I'm not aware of any bug-free software, especially when we're talking as complex as databases. But to tell my your database model has no downsides at all? No use cases where its consistency model isn't optimal, where an implementation detail means that it's not a good fit? Even just skimming the marketing copy, it's clear that if I'm using SQL in my existing app, migrating to FaunaDB has the clear downside that I need to rethink my queries, and that's just the surface layer.
- evanweaver 10y agoBugs was a joke. Analytics is the biggest missing feature...it will come. It's also not cost-effective at the moment for timeseries data. We've updated the posts in light of some of this feedback.
- michaelmior 10y agoI'm not aware of any other services which offer pricing that isn't based on number and size of database servers. Edit: Thanks to all the commenters who corrected me :)
- boulos 10y agoCloud Datastore does exactly that: https://cloud.google.com/datastore/pricing https://cloud.google.com/datastore/pricing Disclosure: I work on Google Cloud (and sit near the Datastore team!)
- itcmcgrath 10y agoTake a look at Cloud Datastore's pricing, which is probably a leader in this area (I work on it).
- wsh91 10y agoFirebase's Realtime Database does this, too. https://firebase.google.com/pricing/ https://firebase.google.com/pricing/ (Disclosure: I work on Cloud Datastore, which is another Google Cloud product; it, too, does pricing based on ops and storage rather than provisioning, as my colleagues note.)
- edaemon 10y agoIt's entertaining that one can make an innocent HN comment about something esoteric like cloud databases and be quickly corrected by three different Google engineers. To provide a non-Google example, AWS DynamoDB's pricing is based on throughput (similar to Google Cloud Datastore).
- wsh91 10y agoHeh. :) One technicality: DynamoDB's pricing is based on throughput, as you know, but it's provisioned throughput. (You manage your capacity unit allocations yourself, at least that was the case a little while ago.) You're charged money for how much you provision regardless of whether or not you actually consume the capacity units. Our pricing model (like Fauna's) only takes ops and storage into consideration.