Hacker News new | past | comments | ask | show | jobs | submit login
MLab is being acquired by MongoDB (mlab.com)
157 points by luceat on Oct 9, 2018 | hide | past | favorite | 88 comments

So I'm happy MongoDB is acquiring additional expertise in hosting...

... but I wish this announcement was a bit different. It says (numbers mine):

1. You will be given plenty of time to migrate, and nothing will be required of you for at least 4 months. We expect to have all customers migrated to Atlas within the next 12 months.

2. Once migrated, your Atlas database will be hosted on similar hardware and cost the same or less than your original plan on mLab.

3. We will provide tools that allow you to migrate with either minimal downtime or no downtime to your application.

I'm fine with the second point. I wish the first and third points instead read:

1. We will publish detailed migration documents by the end of 2018. No action will be required of any customer until a minimum of 9 months after that documentation has been published. We can guarantee all customers following current mLab best practices will be able to migrate with zero downtime should they so choose. As with many migrations, it may be much easier to migrate with a very small amount of downtime, rather than none. To those customers we will offer account credits for their trouble.

I think Mongo is well suited to pure PaaS. Worrying about whether the hardware or software is similar is about the same as worrying about the details of hardware or software. If the needs are very specific, hosting it on a pure PaaS shouldn't be used, but more of an IaaS type of solution.

I think most mLab users rely heavily on mLab's expertise, so if they trust them now it makes sense to trust them after being acquired by a company that's demonstrated interest the type of product they're providing.

Can't say I'm exactly over the moon about this. Although Atlas does seem to be quite a bit cheaper and probably offers a better implementation of the product, mLab's key offering was always the incredibly good support they provide as standard. I haven't needed it often, but I know I can rely on it.

Atlas does not include this - it's something you pay (a lot) extra for and I'm pretty apprehensive about whether it's actually going to be great support or not. At this point my primary worry is that it's going to be more AWS-style support, i.e. expensive and total crap.

The fact that there's no mention of support in the email or blog post does not fill me with hope.

Any Atlas customers who can chime in with their anecdata?

We migrated from Compose to Atlas and their support's been quite good and responsive. Compose was utter crap compared to what Atlas provides.

We did the same (but to mLab) -- we had a terrible experience at Compose

Would you be open to sharing some details about your experience there? I'm building a competing service and want to learn how I can make it great. If you're not comfortable sharing publically, my email is in my profile.

We also left compose but left to move to mLab. When Compose was still MongoHQ, we were really impressed by their support. In the last few years, we became incredibly unsatisfied. mLab has been awesome and responsive. I hope the move to Atlas doesn't cause their support to change.

What didn't you like about the support you got from compose? I'm working on standing up a competing service and would like to learn from your experiences with them.

Can't agree more on the positive comments about mlab. We migrated to them from compose ~2years ago (after horrible support experiences) and have been happy since. At the time, we looked at atlas and their support offerings for affordable plans was just bad. Also, mlab offered a lot of help in the migration while atlas only sent us some sales guys.

Let's see where this takes us.

I had a similar experience with Atlas. At least 1.5 years ago, Atlas felt like a enterprise company trying to do a SaaS. They used the same sales person driven approach I associate with enterprise sales. mLab just felt far more developer focused.

Here's a blog post that outlines the best MongoDB hosting alternatives - ScaleGrid, Compose, and ObjectRocket. All three have free support, and ScaleGrid allows you to keep full MongoDB admin access and SSH access to your machines. https://scalegrid.io/blog/mongodb-acquires-mlab-what-are-the...

AWS is total crap? We received great support and advice for just $30month extra with AWS. It wasn't emergency support granted but helped us with various cloudwatch setup detailsm

I've had the same experience as you. The people behind the support desk have always been able to assist and find an answer for me. Granted to get them to jump on it quickly I usually have to use the "phone me now" option, but the quality has been the same regardless of how I've approached them.

It really depends on your budget for context. If you're running a solo side-project where your database costs are $5-15 a month, paying more than double that just for basic support is a big pain. The cost of support for a single service might end up being more than the total cost of the rest of your stack (VPS/DB/Domain). If you're at a business then sure, $30 a month is no big deal.

Basic support is free. You pay more for better response times and more users being able to open cases. Having said that it is expensive at business level. 10% of your spend if you want the sort of response times you need in production.

Yeah imo. We have the biz support which is 10% of our spend on AWS resources. We only use it for emergencies or dealing with problems caused by AWS, not for help using the products. They simply aren’t that helpful and are never able to actually resolve anything - typically just provide substandard workarounds.

Blog post is missing but mLab is being acquired by MongoDB, here's the press release: https://www.nasdaq.com/press-release/mongodb-strengthens-glo...

I hope this does not mean death to the free 500MB mLab tier. I have been using it for small personal projects with Heroku and have been extremely happy.

Atlas has a free tier with about the same storage limit.

Indeed, but it was very limited in comparison to mLab. Our staging DB was working pretty bad with Atlas (while there were no issues with mLab).

I'm getting a 404. Does anyone have a cached link?

Oddly enough, it seems the article no longer appears on their blog: https://blog.mlab.com/

It's back now.

Not like Mongo to lose Data

(I felt bad about my comment and I'm removing it.)

MongoDB has been deprecated and on the way out at $work for a while now, and we have gradually been rewriting and migrating services to more suitable/sane database tech.

I can confidently say that this migration would have gone a lot faster if it wasn’t for MLab.

They are expensive, but the quality and level of support has been amazing, and this has allowed us to balance building features and addressing other tech debt work, safe in the knowledge that when an overloaded mongo cluster implodes at 3am because the query planner did something stupid, MLab will be there within minutes, and will know exactly how to bail us out.

I've recently done a bunch of research on the best hosting options for MongoDB because we use it at our startup [1] and DB hosting is one of our biggest service expenses.

The major options I found worth considering were Atlas (owned by MongoDB), mLab, and Compose (owned by IBM). Pricing, performance, and versioning all seemed significantly better with Atlas. This narrows the options even more.

I wonder if they intend on jacking up prices once they own the majority of the market, and are one of the only reasonable solutions... I sure hope not.

[1] https://canny.io

Did you look at Azure cosmos? Is that compatible with your setup?

If DB is one of your biggest expenses... why no run your own DB? Paying for someone to spin up instances is quite optional in the big picture. The operational complexity of running a DB is not hard. That said, Mongo is a poor choice for any app ever written. I would question why you would use a best-in-class at nothing Database with many operational issues.

> why no run your own DB?

Running your own DB introduces tons of risk that just isn't worth saving a couple bucks (until you're at the scale that it is).

> That said, Mongo is a poor choice for any app ever written.

Sorry, that just isn't true. It works great for us, and is the 4th most popular database by usage (and growing). https://insights.stackoverflow.com/survey/2018#technology-da...

Using mongo as a DB adds more risk then using self hosted Postgres or MySQL. You can use provider hosted Postgres or MySQL for less money and a better product.

McDonalds is very popular, doesn’t mean it’s good food. Be wary the metrics of success you use.

Can you quantify anything? How does mongo add more risk? How is mysql a better product. It doesn't seem like you're saying anything.

How can it be your largest expense but running your own db would save only a couple of bucks?

We don't spend much :)

Just because it works doesn’t mean it wasn’t a poor choice still.

You could have said the same thing about storing your passwords in plain text.

Bit of a disingenuous statistic. It’s popularity is down to being the default choice for people learning the MEAN/MERN stack. Which is a large number of people currently teaching themselves web dev and goes hand in hand with the rise in popularity of Javascript. It’s got little to do with wether people need a document store or wether it’s good at that job, 99% of the time it’s being used to dump relational data.

1. Only people who have never run their own database at scale make flippant "just run your own DB" statements. Because it is a difficult job to do right e.g. testing of backup/restore, clustering, monitoring etc. Especially if you are a growing startup.

2. MongoDB is a great database if you have a data model that suits it. Problem is a lot of people have treated like it was relational. And operationally it's far simpler than most systems out there.

I run my DB at scale right now. About 2h of work a month. Hint I don’t use mongo.

Both AWS and GCE offer hosted Postgres for less than third party hosted mongo.

What model is good for mango? Postgres has jsonb. Cassandra has large scale data. Mongo is in a weird spot in the middle that isn’t great at anything.

MongoDB is a document store which has much better querying and update capabilities than PostgreSQL's JSONB/HStore. It's also probably an order of magnitude faster when it comes to updates.

Not sure why you brought up Cassandra it is not a document store and completely irrelevant to this discussion.

Postgres used to benchmark faster than MongoDB as a document store when compared to MongoDB running with a reasonable reliability setting. Not sure if that has changed in the last few years though - Mongo has improved a bit, and Postgres is getting faster on each release.

Let the tired old irrelevant Mongo-flamewars begin!

As much as I agree, the arguments are a bit tired, I think the criticism can be useful.

There's a tendency in web development towards using well known stacks, and some of them are quite poor choices for most projects. MongoDB features heavily in these stacks despite relational databases being a better fit most of the time, possibly because there's less visibility of alternatives in the JS community.

Do you think the OP is storing documents? I will put cash money they are doing something like the MEAN stack and storing relational or semi relational data in Mongo. Not many startups spend the majority of their storage storing documents.

Shouldn't be illegal to buy a competitor that do exactly the same things as you when the sum of the market share is greater that 50% ? I know it depends on the definition of the relevant market that could be "hosted mongodb" ( mlab+atlas are maybe 70% of the market ) or "hosted documents DB" (maybe 40%) or "hosted DB" (maybe 5%). What do you think ?

The issue is whether it's bad for the customer, right?

There's the possibility that things could worsen, as there's the loss of competition. There's also the possibility things could improve, as there could be a concentration of effort on one product-suite rather than several.

I'm inclined to be optimistic in this case, as there's still competition from non-managed Mongo. If they go nuts with their price-point, people have the option to just dump them and manage their databases themselves.

They don't have proper lock-in, as the data can be exported with relatively little fuss. They earn their keep by delivering value to the customer month after month.

I think in all case I'm better when I can choose between mlab or Atlas than when I've no choice. The US has an history of allowing monopolies that I really can't understand, for exemple Facebook acquisitions or more recently, GitHub.

True, but these are small players, not enormous corporations, so I'm less cynical.

qui vivra verra - time will tell

Maybe it's time to lauch a competitor, by starting new leveraging kubernetes or whatever new tools exists now and by benefiting the time they will spend merging products and teams.

If you think it would be quick, safe, and easy to produce a competing product of the same quality, then absolutely.

I haven't used Atlas but I recall in 2013 mLab being a pretty solid experience. A lot of great features for a reasonable price.

Anyone have an idea at what market share looks like for for MongoDB hosting these days?

As an aside I recall Rackspace buying ObjectRocket when it when on it's SaaS / PaaS buying spree in 2013. Did RAX ever spin it off?

ObjectRocket is still owned by Rackspace - but they don't seem to be very integrated. ObjectRocket are still doing their own thing, fairly independently of the main Rackspace service.

> As part of combining the two companies we will be sunsetting the mLab service and migrating all customers to MongoDB Atlas.

MongoDB really consolidating the Mongo hosting market

Wonder if Compose.io will be next? Their initial marketing push seemed to be largely toward Mongo, I see they support other DBs now

IBM already bought Compose a while back.

I do wonder about latency. Unless you’re in the same zone in the same cloud, surely your queries are gonna be slow-ish.

You don't have to be in the same zone or the same cloud, you just need be in roughly the same DC area and buy 10 Gig Direct Connect links from AWS. This is possible in places like London, Ashburn, VA, Dublin which is why many of these providers only offer their service in a subset of a cloud providers locations. The latency is is basically imperceptible ~1-2ms.

You can get an awful lot of customers just by being in Ashburn VA with direct connects to to the big cloud providers. Most queries to a DB like mongo are slow enough that 1ms of network latency is just noise.

> Most queries to a DB like mongo are slow enough

Strange. MongoDB has been consistently the fastest database I've ever used. Especially if your data model is document orientated.

Really? Stock Postgres is faster than a well-optimised Mongo deployment, in my experience.

(Apples to oranges, sure, but Postgres has the capability to be a great document store as well.)

> Especially if your data model is document orientated.

You shouldn't be using MongoDB for anything but documents.

Doesn't mean it might not change hands again! (as unlikely as that would be)

As for latency, with Mlab you were able to specify the cloud provider and zone IIRC, not sure if other competitors like Compose have that

> with Mlab you were able to specify the cloud provider and zone IIRC

That's correct, you specify a provider and region but can also set up VPC peering so all traffic remains within AWS' network within a region. I've used this setup - mLab on AWS with VPC peering and it worked great.

But specifying the zone won't help since zones are not consistent across different accounts, so while you can ensure your in the same region, you may still end up talking across different data centers. Do they have anyway to handle this?

The same features exist in Atlas, so you should be good to go there.

Compose is hosting other types of databases now. I think the move for Mongo is to be THE platform for Mongo developers

Compose.io is owned by IBM

Why is "Hosting" capitalized? Is it a proper noun? I don't get it.

One of the mods changed the title for no reason. Not only did they make a typo, they changed it from the article's real title.

> You will be given plenty of time to migrate, and nothing will be required of you for at least 4 months.

I hope they will publish migration tools and docs soon. So there is enough time to migrate.

While sometimes a longer timeframe to migrate is better (often, most times), there are edge cases where you want to migrate immediately after an announcement like this. For us, we'd like to get this done by next week. The sooner the better to avoid any schedule disruption thereafter.

Another MongoDB as a Service, especially useful for european looking for a MongoDB hosting in EU: https://scalingo.com/databases/mongodb

NodeChef MongoDB hosting is an option worth considering for hosting databases. https://www.nodechef.com/mongodb-hosting

curious to know how many ex-mongodb are now on AWS Athena?

I work for AWS but previously worked for MongoDB.

I don't think the two are really comparable - completely different querying paradigms. Athena works by writing SQL queries against JSON, CSV, or other kinds of documents stored in S3. You pay per request and per GB scanned as part of your query.

MDB is a fully fledged database that can do aggregations, queries, etc.

I consider those two products addressing totally different problem sets but if you've found places where they're the same I'd be interested in learning more.

nvm i meant AWS dynamodb

Original title is "mLab is becoming a part of MongoDB, Inc."

Curious--are you saying you changed it? If so, why?

GP is not OP. HN has a try not to editorialize titles rule, so GP was pointing out the title was changed:

"Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."


Not sure why the title got changed, "MongoDB acquires mLab" seems to make more sense.

We've reverted it to the original from “MongoDB acquires a database Hosting company”.

Makes sense. Then I agree with the parent comment. Odd change made here

Yeah sorry, I was pointing out that the original title was different than the posted one (due to the HN guideline as explained by ibotos). Also it included the name of the acquired company.

Are we still paying attention to MangoDB

People love to hate on Mongo. Honestly these days it's really completely undeserved.

As long as you've bothered to actually read the docs on the things you're using before you use them, it will do just fine. Just because the drivers' default configurations are different from other DBs does not make it fundamentally bad.

IMO it's a fantastic DB and I constantly wish Postgres would get anything like the complex-object querying support that Mongo has.

> [...] I constantly wish Postgres would get anything like the complex-object querying support that Mongo has.

Any chance you could describe a bit more what you'd like?

With Mongo, assuming a document like:

    { "arr": [{ "a": [{ "b": 5, "c": true }] }] }
You could query it with:

    { "arr.a.b": 5 }
And you can create indexes for that. To my understanding, you can’t even get close to that with what Postgres currently supports.

That works. A bit different syntax, but it works:

  -- create a table with data
  CREATE TABLE arrs AS SELECT format('{ "arr": [{ "a": [{ "b": %s, "c": true }] }] }', g.i)::jsonb AS data FROM generate_series(1,1000) g(i);
  -- index, this one only supports "rooted" paths, but you can create one that allows searches not starting from the root too
  CREATE INDEX idx ON arrs USING gin (data jsonb_path_ops);

  -- search
  postgres[22708][1]=# SELECT data->'arr' FROM arrs WHERE data @> '{"arr": [{"a":[{"b":5}]}]}';
  │            ?column?            │
  │ [{"a": [{"b": 5, "c": true}]}] │
  (1 row)

  -- show index usage
  postgres[22708][1]=# EXPLAIN ANALYZE SELECT data->'arr' FROM arrs WHERE data @> '{"arr": [{"a":[{"b":5}]}]}';
  │                                                 QUERY PLAN                                                  │
  │ Bitmap Heap Scan on arrs  (cost=20.01..24.02 rows=1 width=32) (actual time=0.131..0.132 rows=1 loops=1)     │
  │   Recheck Cond: (data @> '{"arr": [{"a": [{"b": 5}]}]}'::jsonb)                                             │
  │   Heap Blocks: exact=1                                                                                      │
  │   ->  Bitmap Index Scan on idx  (cost=0.00..20.01 rows=1 width=0) (actual time=0.107..0.108 rows=1 loops=1) │
  │         Index Cond: (data @> '{"arr": [{"a": [{"b": 5}]}]}'::jsonb)                                         │
  │ Planning Time: 0.107 ms                                                                                     │
  │ Execution Time: 0.186 ms                                                                                    │
  (7 rows)

You can make an argument that the mongo's path description is easier to write, but "you can’t even get close to that with what Postgres currently supports" doesn't seem accurate.

Edit: formatting

I believe that only works if it’s the first item in the array right?

Having done more reading up though, it sounds like composite types are actually a better solution for PG, though then they come with their own set of caveats/limitations :\

> I believe that only works if it’s the first item in the array right?

No, it works regardless of that.

Maybe if they acquired a db company.

They kind of did when they bought the WiredTiger engine.

Ever since then it's been an extremely fast and solid database.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact