
MLab is being acquired by MongoDB - luceat
https://blog.mlab.com/2018/10/mlab-is-becoming-a-part-of-mongodb-inc/
======
preinheimer
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.

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

------
BillinghamJ
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?

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

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

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

------
manigandham
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...](https://www.nasdaq.com/press-release/mongodb-strengthens-global-cloud-
database-with-acquisition-of-mlab-20181009-01109)

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

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

~~~
guzik
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).

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

~~~
thsowers
Oddly enough, it seems the article no longer appears on their blog:
[https://blog.mlab.com/](https://blog.mlab.com/)

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

------
a13n
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](https://canny.io)

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

~~~
a13n
> 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...](https://insights.stackoverflow.com/survey/2018#technology-databases)

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

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

------
julienfr112
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 ?

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

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

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

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

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

------
upbeatlinux
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?

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

------
thsowers
> 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

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

~~~
thsowers
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

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

~~~
ecnahc515
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?

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

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

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

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

------
yannski
Another MongoDB as a Service, especially useful for european looking for a
MongoDB hosting in EU:
[https://scalingo.com/databases/mongodb](https://scalingo.com/databases/mongodb)

------
squid3
NodeChef MongoDB hosting is an option worth considering for hosting databases.
[https://www.nodechef.com/mongodb-hosting](https://www.nodechef.com/mongodb-
hosting)

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

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

~~~
browsercoin
nvm i meant AWS dynamodb

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

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

~~~
lbotos
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."

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

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

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

------
vmchale
Are we still paying attention to MangoDB

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

~~~
anarazel
> [...] 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?

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

~~~
anarazel
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

~~~
BillinghamJ
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 :\

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

No, it works regardless of that.

