HN Explorer

Ask HN: Why “database as a service” didn't succeed?

10 points by twa927 ↗ HN
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.

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?

10 comments

[ 4.0 ms ] story [ 7.5 ms ] thread
ronreiter
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.

Database as a service works just like any other managed service today.

twa927
I wouldn't say they are widely adpoted now. Maybe the switch is happening now?

And I'm not sure all the mentioned products are fully abstracted, for example BigTable docs mention "nodes".

fragsworth
From my own experience, among projects currently in development, these services are pretty much widely adopted. Very few people host their own databases, and I will usually advise against it unless there are unusual security reasons (e.g. you cannot trust Amazon or the NSA).

Many old projects, due to costing some amount of time/labor to switch, will likely never move to these database services.

Gigablah
There's also the hosted CouchDB offering by Cloudant (acquired by IBM).

Also, just because documentation mentions something that happens beneath the hood, or companies give you finer control over your service configuration, that doesn't mean it's not "fully abstracted". You'd probably want your database in a datacenter close to your target market, for example.

smt88
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.)

That's really only possible if the DBaaS is a "thin wrapper" as you describe.

But, other than that, I think ronreiter is right -- there are DBaaS that have big user bases.

cjlarose
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.

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.

nostrademons
Most of the MBaaS market is basically database-as-a-service.
jbergens
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.

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.

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.

kasey_junk
"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.

Once you do that, things like instances/nodes/hosts become important because you cannot abstract certain consistency requirements away from them.

SHOwnsYou
Latency. If you're already hosting on AWS or GCE, using their databases is commonplace.

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.