

MongoHQ releases SSD powered databases, autoscaling beta - mrkurt
http://blog.mongohq.com/blog/2013/02/27/now-available-available-SSD-replica-sets-beta-autoscaling/

======
nodesocket
MongoHQ is awesome, and their control panel is hands down the best of the
MongoDB PaaS, but their pricing is cost prohibitively expensive.

For example, you can get a 2 core, 2GB memory, 20GB of SSD backed storage from
DigitalOcean for $20 a month. So, buying three VM's from Digital Ocean for a
replica set is a total of $60 a month. Essentially the same thing at MongoHQ
is $500 a month.

I completely understand that you pay more for using a PaaS, but that much
more?

~~~
tedchs
With a username like "nodesocket", I assume you are not their target audience
as you are just as comfortable rolling your own and getting your own 10gen
support contract.

~~~
nodesocket
Actually I've used MongoHQ as well as MongoLab for development, but for
<http://commando.io> it made sense to just purchase three virtual machines on
Softlayer and setup MongoDB. Backups we quite easy as well, a few hours later
we had a working bash script which stored backups locally, and well as synced
them to S3.

------
andypants
Can somebody explain why mongodb storage space is always so expensive and
limited on mongodb hosting services? (Not just these SSD plans)

And the plans also start with so little space

~~~
jacques_chester
Because it's more profitable for them to charge more.

~~~
saalweachter
And they're catering to people who either (a) don't know how cheaply you _can_
run a database or (b) know how expensive it is to run a database _well_.

The number of times I've seen a database go down in production either because
it's solitary mirror failed with no one noticing or because it wasn't consider
"mission critical" enough to _have_ a mirror... you're not just paying for the
hardware, you're paying for the guys managing the hardware. If you're a
company with databases and you don't have someone on staff whose primary job
is making sure your databases still exist from day to day, one day they won't.

~~~
_neil
This. We have a small team for a particular project I'm on and we were
initially hosting mongo ourselves. After reading so many horror stories, we
felt much more comfortable outsourcing configuration, management, and backups
until we get to the point that we can have a dedicated DB person.

~~~
jacques_chester
Given that you were motivated by "horror stories", did you also consider
changing data stores?

~~~
_neil
That's fair. Yes, we did consider changing. But we haven't had any issues
ourselves or a real need for a structured database at this time. If we do in
the future, transitioning won't be extremely painful because most of our
historical data isn't critical; it would mainly just be user accounts.

For us, saying, "oh shit, a handful of other people had a bad experience – we
should drop everything and move our data to postgres" would have been a bad
decision and a waste of time/money.

~~~
jacques_chester
Thanks for the reply. I'm a pro-RDBMS bigot, but path dependency is path
dependency. In your position I would probably make the same decision.

------
ig1
As far as I can tell they don't offer either SSL or SSH tunnelling, so there's
no way you can securely connect to the database remotely. Without those you're
sending your password and data unencrypted over a public network.

By default Mongo uses MD5 for password hashing (with username as seed) so it's
not secure to use it over a public network.

(if your server is co-located on the same network as MongoHQ then you can
probably hack it using network access rules)

~~~
benwyrosdick
We do offer an SSL option if you email support@mongohq.com

------
fiatmoney
My impression has been that Mongo has great performance as long as your
working set is totally in RAM, after which it craters (due to the use of
MMAP'd files as the core storage engine and relying on the OS's paging algos).
To what extent is this true on SSDs? Can you get away with a higher working-
set-to-RAM ratio?

~~~
mrkurt
We've generally found that 1GB of RAM per 10GB of data is best for common
Mongo setups. SSDs make a huge impact on the to-disk performance, which does
help with the working set.

SSDs also help with writes and can help mitigate the infamous global write
lock problems in Mongo.

~~~
bifrost
Any tests on ZFS?

------
tedchs
I don't understand all the hate about MongoHQ's pricing. I run a Mongo replica
set in production on bare EC2 and it works well, but there is a lot of
reading/research involved in setting it up _correctly_ and handling any Mongo
issues that arise. Nothing stops you from doing that, and 10gen even provides
a beautiful AWS CloudFormation template to make it easy to provision a replica
set with EBS RAID. However if I were not a senior-level Linux engineer I would
totally go for a managed service for anything that was revenue-generating.
Assuming it's not a personal/bootstrap situation, spending a few hundred bucks
a month is better than risking downtime, or just as bad, scaling pains. The
value in MongoHQ and others is their people, not their hardware.

~~~
andypants
It's not the pricing I don't like, it's the relationship between pricing and
storage space. I doubt when I go from a 0.5GB database to a 1GB database that
they have to double their support team as well.

Heroku's postgres is just as (or more) expensive as mongohq/mongolab, but they
don't limit storage at all (except at the dev tier plans).

~~~
mrkurt
<\-- MongoHQ Cofounder here

Database storage space correlates pretty well to the management complexity, at
least with our customer base.

Offering unlimited storage on a DB is somewhat disingenuous, there are
effective resource limits that matter long before disk space and those (RAM/IO
capacity) are the things that cost actual money.

~~~
jongleberry
is there a possibility of foregoing EBS storage, using instance storage, and
creating incremental backups to S3 using a secondary server on a replica set?
is there a reason this would be a bad idea? seems like it would cost a lot
less.

------
patrickod
We've used MongoHQ extensively for the last 2 years and have always found them
to be excellent. The team is both incredibly dedicated and knowledgable. They
are the experts in anything MongoDB related. If you're thinking of using
MongoDB you should use them. No questions asked

