Wouldn't that slow down an application to have every database call go over the internet?
I guess for most sites, users won't really notice a few hundred milliseconds. I mean, most websites take many seconds to load when you factor in all the individual files and images, etc.
UX performance is more about perceived delay (by end-users, not us technical folk) rather than actual delay. If you want to use a product like this so you no longer have to think about your database (and are willing to pay what seem to be quite high fees), design your application to account for the fact that there will be large amounts of lag... that's what parallelisation and non-blocking IO is for.
If you have a pure ajax app that's directly hitting the db, then it starts to make some sense, as this isn't too much slower than it would be to hit your own service backed by a local db (though 300ms is definitely on the slow side for queries). This seems to be the use case they're aiming for given the focus on end-user authentication.
We'll see in 2011 I guess.
It might be different if you do bulk uploads of data and then spend a lot of time querying it and retrieving relatively small reports - but that's probably not what most applications spend their time doing.
Also, once you cache them to avoid hitting a backend xSQL store you can also cache them to avoid hitting a remote SQL store, I imagine.
Bigger concern: How exportable is this database (my guess is very, since its a resful api to access it all) because at some point if they fail, you going to need to move to your own cluster.