

Great Business idea #2: Managed MySQL or PostgreSQL on SliceHost and EC2 - pelle
http://stakeventures.com/articles/2008/10/30/great-business-idea-2-managed-mysql-or-postgresql-on-slicehost-and-ec2

======
mdasen

        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.

~~~
pelle
$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.

------
olefoo
If you want a managed PostgreSQL instance CommandPrompt offers that as a
service <http://commandprompt.com/services/dedicatedhosting/>

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.

------
tptacek
I wouldn't trust a shared instance of MySQL with blog comments, let alone
business data.

~~~
pelle
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.

~~~
tptacek
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.

