MLab is being acquired by MongoDB
blog.mlab.com
blog.mlab.com
... 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 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.
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?
Let's see where this takes us.
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.
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
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...
McDonalds is very popular, doesn’t mean it’s good food. Be wary the metrics of success you use.
You could have said the same thing about storing your passwords in plain text.
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.
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.
Not sure why you brought up Cassandra it is not a document store and completely irrelevant to this discussion.
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.
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.
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.
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?
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
I do wonder about latency. Unless you’re in the same zone in the same cloud, surely your queries are gonna be slow-ish.
Strange. MongoDB has been consistently the fastest database I've ever used. Especially if your data model is document orientated.
(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.
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
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.
I hope they will publish migration tools and docs soon. So there is enough time to migrate.
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.
"Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."
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.
Any chance you could describe a bit more what you'd like?
{ "arr": [{ "a": [{ "b": 5, "c": true }] }] }
{ "arr.a.b": 5 }
-- 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)
Edit: formatting
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 :\
No, it works regardless of that.
Ever since then it's been an extremely fast and solid database.