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"?
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".
Otherwise, congrats on your launch!
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.
https://googlecloudplatform.github.io/google-cloud-node/#/do...
and like Dan said, you can come over to Cloud Functions now if you'd like ;).
Disclosure: I work on Google Cloud.
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.
How does this work? Is the Datastore data available locally in every region? Docs don't make this clear.
We were looking for something like DocumentDB that has replication to any region you want to run in.
https://cloud.google.com/datastore/docs/locations
(Not sure about the rest.)
I should note that part of our deployment is on Google Compute Engine, and we like it.
[1] https://cloud.google.com/datastore/docs/concepts/transaction...
[2] https://cloud.google.com/datastore/docs/concepts/indexes
[3] https://cloud.google.com/docs/geography-and-regions#multi-re...