These links are much more informative:
https://developers.google.com/datastore/docs/concepts/
https://developers.google.com/cloud/pricing#cloud-datastore
"Unlike traditional relational databases, the Datastore uses a distributed architecture to automatically manage scaling to very large data sets. ..
Datastore reads scale because the only queries supported are those whose performance scales with the size of the result set (as opposed to the data set). This means that a query whose result set contains 100 entities performs the same whether it searches over a hundred entities or a million. This property is the key reason some types of queries are not supported."
"You should be aware that Cloud Datastore has a serving component that runs on Google App Engine, so there will be instance hour costs."
It is only after reading this bit that I went, d'oh, this is the same Datastore that you use on App Engine, abstracted and factored out. So basically you don't need your app to run on App Engine to use it anymore -- this is what the noise is about. Got it. Sheesh could have just said that. :)
The most comparable thing seems to be providers of Big Ass CouchDB in the cloud like: https://cloudant.com/
From a market perspective, it kind of makes no sense. I challenge CTO/CIOs to justify building their company on a closed source critical product with no option. While that used to be how things worked in the 90s, I don't think that is as acceptable as it used to be.
Maybe the answer is "well it's the only thing that works", in which case I congratulate you for building such an in demand product!
As for the vendor lock, most of the datastore API is very similar to other nosql APIs I've seen. It wouldn't be trivial to switch, but not impossible either. I imagine it'd be even easier if you used a orm that is widely supported but I stay away from those, so I couldn't say for sure.
Sadly, I disagree. While it isn't SOP for a startup to go down this route, many companies still end up dealing with vendor lock-in.
Unfortunately, Google is going to continue dealing with the stigma of abandoning and sunsetting their own product line, regardless if it's not happened in the enterprise sector. I just don't trust them.
On the downside it can't do aggregates, it can't do query filters on more than one property, it can't do joins, it has its own unique query language, and it is a proprietary system with no chance of moving to another provider or hosting it yourself.
Speaking of it having its own query language, perhaps that isn't a big deal given you can't do any non-trivial queries.
For me, the pejorative NoSQL claim is actually a marketing turn off.
I am excited and will gladly try it on some side projects.
If you want to charge for instances then the way to do it is the DynamoDB’s way — charge for throughput. The actual number of instances should be an implementation detail. At least that way it’s deterministic and you can feature it prominently on your pricing page with an appropriate calculator.
Until then the advertising is completely misleading if not dishonest, since I’m pretty sure the instance costs would be quite significant for any use case that tries to use “Cloud Datastore” as a standalone db solution for GCE ecosystem, rather than to just run some Map Reduce for an App Engine app.
My opinion changed when I started working as a contractor at Google 2 months ago. I love the Google infrastructure, from inside the company. It is amazing (that is an understatement!). When my project is done next year and I go home, I am fairly sure that I will go back to using AppEngine, and other services for my own projects just out of nostalgia.
For the general public, I am not sure if the AppEngine and other Google services story is a good one though. It will be interesting to see how their market share for the PaaS does over the next few years.
I definitely hope they plan to include ndb in their googledatastore library. I feel like ndb is the actual selling point to me, and would make me really want to use this for a production app.
