I'd hapily pay $10-20 for a low volume plan and considerably more for high volume
How much more? The problem is that, while it's easy to run My/PostgreSQL, it's hard to keep them always on, perfect data integrity, etc. On the lowest end, it's going to cost you at the very minimum $50/month to offer this service. You need two slices starting at $20 a piece plus backups which I'm just fudging at $10/mo.
So, you say put multiple clients on a 256MB slice? At what point does that become unfair? I wouldn't want my database to have less than 64MB to its name. So, 4 clients per $50 even for small users? That won't hit a $10/mo price point.
Yes, you can get more beefy slices like the 15.5GB slice which could accommodate 248 people offering 64MB a piece (you could probably load this one more since the likelihood of users who under use is greater in greater numbers). Still, assuming you have 300 people on the box, that's a cost of $5.33 per user in equipment alone.
BUT, you're service is supposed to scale, so you can't really even put the 248 people on the box because you need excess capacity for when a customer says, well, I want more capacity. I mean, are you going to say, "yes, we scale, but we have to take your database offline for half an hour, find a new box for it and then put it back up. and it'll be that way every time you need more juice."
It also misses what makes databases tick: RAM and disk. EC2 and slices can do well on the RAM front, but again, once you give someone the RAM, the costs go up huge. In terms of disk, slices are just bad. No one would claim Xen should be used for a good database server because it's not great for disk i/o.
Plus, scaling a database isn't usually an issue of knowing a database - it's about knowing queries. So, if you're putting a scaling guarantee in there, you're offering to write people's code for them.
The fact is that databases aren't headaches for people getting 10,000 hits per day unless their queries are grossly wrong (which this service wouldn't fix). If you're a big site, you probably want something better than they could offer.
*Oh, and for anyone who wants this service, it already exists with RightScale. Only problem is that it's way out of the quoted price range.
$10-$20 means low volume. Similar to what you might expect on a small virtual hosting plan. For medium volume, I would happily pay the equivalent of the cost of 1-2 slices for a managed service.
I think a metered plan might be the best option though. There are lots of ways of extracting statistics from a database server. I am a bit unsure how what parameters you would use to meter the plans, but there are lots of metrics you can use. Storage, queries, cpu etc.
There are definitely limits for how much you could scale performance wise on something like this, but that isn't even the point. It's about high availability and not having to manage it.
If you're at the point where you need a facebook size database cluster for your site, this service probably wouldn't be for you.
The issues with running a database in a shared environment are that you need dedicated hardware for performance, you do not want to be telling customers that you don't know why it takes 10 seconds to update inventory quantities only to discover it's someone else sucking up your disk bandwidth.
And as Thomas points out the security considerations alone should kill the idea; it's possible for someone with administrative access to dump the contents of memory on a VM (how VM migration works) and at that point any private keys you are using to provide "transparent encryption", or any inflight customer business data is fair game.
Properly configured MySQL can safely be partitioned. This is what EngineYard does and what every single virtual host provider does. I fail to see a difference.
If you don't trust a service provider, you shouldn't use them. It is up to the company providing the service to instill trust in their services.
You use this word "safely" as if you had some ability to know that. You don't. Consider rewording.
The vast majority of MySQL deployments conceal the MySQL connection handler from end-users --- in the vast majority of deployments, it's the web app stack talking to MySQL, not the client. Virtually all security testing of MySQL is done to that service model.
"Partitioned" MySQL is a totally different service model, where the attacks aren't simply string escapes or column truncation through HTTP post-args, but arbitrary SQL syntax, arbitrary MySQL commands, and the MySQL network protocol itself. That service model has received very little security testing. Some data points for context:
* The second model implicates vastly more MySQL code, which has to be bug-free for this to be safe.
* No major database has survived intensive post-auth security testing; Litchfield's results on Oracle --- a database that got millions of dollars of security attention internally --- were all post-auth; that testing happened after he (presumably) beat the crap out of Microsoft SQL Server.
* Even if you "partitioned" MySQL into multiple running instances of mysqld running under different UIDs in different filesystem paths --- which is not what this article is implying --- a vulnerability in that MySQL code still gives an attacker code execution on your database server, which would be a game-over problem in a commercial app.
So, you say put multiple clients on a 256MB slice? At what point does that become unfair? I wouldn't want my database to have less than 64MB to its name. So, 4 clients per $50 even for small users? That won't hit a $10/mo price point.
Yes, you can get more beefy slices like the 15.5GB slice which could accommodate 248 people offering 64MB a piece (you could probably load this one more since the likelihood of users who under use is greater in greater numbers). Still, assuming you have 300 people on the box, that's a cost of $5.33 per user in equipment alone.
BUT, you're service is supposed to scale, so you can't really even put the 248 people on the box because you need excess capacity for when a customer says, well, I want more capacity. I mean, are you going to say, "yes, we scale, but we have to take your database offline for half an hour, find a new box for it and then put it back up. and it'll be that way every time you need more juice."
It also misses what makes databases tick: RAM and disk. EC2 and slices can do well on the RAM front, but again, once you give someone the RAM, the costs go up huge. In terms of disk, slices are just bad. No one would claim Xen should be used for a good database server because it's not great for disk i/o.
Plus, scaling a database isn't usually an issue of knowing a database - it's about knowing queries. So, if you're putting a scaling guarantee in there, you're offering to write people's code for them.
The fact is that databases aren't headaches for people getting 10,000 hits per day unless their queries are grossly wrong (which this service wouldn't fix). If you're a big site, you probably want something better than they could offer.
*Oh, and for anyone who wants this service, it already exists with RightScale. Only problem is that it's way out of the quoted price range.