Even the database services from cloud providers, like Amazon RDS or GCE, are effectively thin wrappers over traditional database components. "Instances", "nodes", "hosts" are still present and not abstracted.<p>It looks like a database as a black-boxed CRUD API, with abstracted node/replication/failover handling, should be the obvious solution. I think there were tries to do it (Amazon SimpleDB, Google AppEngine's datastore?) but they are not widely used. Why?
Amazon's DynamoDB is widely adopted. Google's datastore is widely adopted. And Google just added a generic interface to BigTable. And there's also Google's Firebase.<p>Database as a service works just like any other managed service today.
Depends on what you mean. There are databases that are mostly handled by the hosting firm. MS Azure can be used in failover mode and you can scale up to more powerfull "servers" without taking the application down. Sql databases are normally hard to scale-out over many servers and often require some rewriting of the application to do scale-out.<p>IBM Cloudant can scale-out to many servers that are all handled by IBM. I'm sure a lot of other cloud based documentdatabases can do this too.<p>Regarding why it hasn't become really popular yet organizations are generally very slow to change their data storage solutions. Changing to nosql from a relational database also requires a large rewrite of the system and it is not only upsides of going in this direction (some says that it is almost only downsides). It is for exmaple usually harder to get acid guarantees from a distributed db and it may be harder to create (secondary) indices.
I like RDS because I get control over the app-specific things (structure, indexes, etc.) and don't worry as much about general DB issues (backups, slaves, I/O performance, etc.)<p>That's really only possible if the DBaaS is a "thin wrapper" as you describe.<p>But, other than that, I think ronreiter is right -- there are DBaaS that have big user bases.
FWIW, if you configure AWS RDS for Multi-AZ support, you essentially get a black box "cloud database" with synchronous replication and automatic failover. You're right, though, in that you're still essentially being allocated a fixed-sized single-node deployment of your favorite RDBMS.<p>I think the "obvious solution" is just not super easy to implement. If you want ACID compliance as with traditional RDBMSs but in a auto-scaling, distributed setting, it's not going to happen. Early RDMSs were built with a single node in mind, and any database-as-a-service will have to make some compromises. DynamoDB gives you the flexibility of not having to worry about scaling, and even offer strongly consistent reads, but without support for transactions, for example.
"Database" is not specific enough. You have to get to very specialized consistency requirements before you can start talking about what you mean by a database.<p>Once you do that, things like instances/nodes/hosts become important because you cannot abstract certain consistency requirements away from them.
Latency. If you're already hosting on AWS or GCE, using their databases is commonplace.<p>But if you host your frontend, it doesn't make sense to talk to a database in a different datacenter when you could instead put it in the same rack.