Comment by akerl_ | Hacker News Reader

Comment by akerl_ | Hacker News Reader

Parent Full thread

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-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.

Understand. 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.

I'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.

Bugs 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.

I'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 :)

It'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).

Heh. :)

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.

Ah, so just like SDB. I wonder why AWS moved on from that model.

I thank you for the compliment, but I am a lowly PM rather than an engineer, that doesn't find Cloud Databases [1] any more esoteric than the Cloud in general. :)

You'll probably find there are a lot of distributed database geeks at Google, me included, so we all get attracted to exciting posts on new distributed systems.

[1]: http://db-engines.com/en/blog_post/68

I can vouch for itcmcgrath's lowliness.

One of the reasons I love HN :)

Firebase's Realtime Database does this, too.

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.)

Cloud Datastore does exactly that:

https://cloud.google.com/datastore/pricing

Disclosure: I work on Google Cloud (and sit near the Datastore team!)

Take a look at Cloud Datastore's pricing, which is probably a leader in this area (I work on it).

Reply on news.ycombinator.com