By "Serverless", do you just mean DBaaS? "Serverless" in the context of a database is kinda weird because the data does have to be stored somewhere. This branding doesn't make much sense to me.
> It’s relational, but not SQL.
Why not SQL? Is there something your query language supports that SQL doesn't?
> With pay-as-you-go pricing, your database costs nothing when no one is using it. Combine it with a function-as-a-service provider like AWS Lambda or Google Cloud Functions, and your entire cost structure scales dynamically with usage.
In provisioning terms, how is FaunaDB different from existing alternatives like Google Cloud Datastore? What makes it "Serverless"? Are you just saying PAYG = "Serverless"?
It is similar to datastore, but with full-blown database features like transactions, joins, multi-region replication, temporal history, covering and compound indexes, graph queries, stored procedures, etc., and you can run it on-premises if you want (currently in beta).
We also have multi-document transactions, self-joins, active-active multi-region replication by default, secondary indexes, composite indexes, a SQL-like query language, PAYG model with no capacity planning, etc, so I think it's a bit disingenuous to say it's "similar to datastore, but with full-blown database features".
I like Google Datastore alot - I think it is the best of the serverless databases at the moment, assuming you are wanting to build "normal" crud style web applications to store stuff and query it in a way that is reasonably familiar to most programmers. It's great and well thought out.
The weird thing about Google Cloud Datastore is that its essentially got no real search functionality.
I say "weird" because, well, it's Google and you'd think that the search thing would pervade everything.
I recently had need of a serverless database, and I'm a huge fan of AWS and I use AWS Lambda but AWS really lets its side down with its serverless databases DynamoDB and SimpleDB, neither of which, in my opinion, are usable for "ordinary" applications.
So in the end I implemented Google Cloud Datastore in my AWS Lambda functions.
After a couple of days I bailed out on the strategy and installed Postgres on an instance and now I'm using that.
There were several reasons to finally go (back) to Postgres. First, the Google Cloud SDK for JavaScript was huge which was a nightmare for uploading AWS function zip code. Second it made me really nervous that I couldn't do any sort of LIKE or search query, which I need in my application. Third the documentation for DataStore was good but not great and there wasn't alot of third party stuff written on it. Given it was early in my project I decided to retreat to the safety of Postgres to avoid buyer regret.
I still feel that there is a real need for better serverless databases - Google Cloud Datastore has my vote as best so far but not ready yet for the sorts of thing I want to build.
I happy to hear you gave it a shot and I've heard several times about it being used successfully from Lambda (hopefully people can look at GCP's Cloud Functions now, but I'm biased). Sorry to hear it didn't work out.
Search is something we're looking at, and we have a high quality bar on reliability and scalability aspects as a service that handles 10's of trillions of requests per month.
I'll also pass on your feedback about the JavaScript SDK to its team.
I tried with only the google cloud datastore SDK and it took the zipped(!) filesize down from 23 meg to 18 - not a substantial difference.
And AWS has me hooked on its cognito service so I'd never even be able to try Google Functions because as far as I know there is no Cognito equivalent in the Google ecosystem. Cognito is awesome.
I can't speak to the SDK parts, but take a look at Firebase's suite more broadly. :) Viz a viz Cognito, check out Authentication and the Realtime Database in particular.
Datastore can be created in multi-region configurations. This is deployed over multiple regions in a single continent/nearby geographic areas, e.g. USA, Europe, and Asia. Google Cloud Storage has the same features.
We have a series of locations that determine replication topology, but you cannot do à la carte region selection at this time. Under the hood we run on at least 3 independent private super fast network fabrics between regions, so we have a pretty high bar infrastructure wise for deployments. We bet on having reliable high-grade deployments and Google's world wide network to get requests to users faster rather than stretching out arbitrary deployments. Seems to work so far for customers like Snap & Niantic Labs (Pokemon GO), but YMMV.
We also have transactions [1], compound indexes [2] and multi-region replication [3]. I'm not sure what defines a "full-blown" database, but that much is true.
By "Serverless", do you just mean DBaaS? "Serverless" in the context of a database is kinda weird because the data does have to be stored somewhere. This branding doesn't make much sense to me.
> It’s relational, but not SQL.
Why not SQL? Is there something your query language supports that SQL doesn't?