I'm Done With MongoDB... It's Leaving My Stack

Planet Earth
3

If I could use any DB with no issues it would not be MongoDB. I’m getting ready to build an app for myself and i’m choosing RethinkDB for that. There’s already a beta Rethink package and it’s built in real-time features make it a shoe-in after SQL support. I’m betting it’ll come soon after that (de-coupling mongo will be the hardest part of the SQL transition).

It’s like MongoDB but done right. The ReQL language is also very very nice as it has a ‘functional’ approach to build up a query. First class joins are really nice.

They use the Jepsen test suite to test all builds against edge cases which fails bad with Mongo and even Postgres had a small issue.

However this DB is not very old so it could end up in the same boat. It’s at 2.x and production ready and has been getting a lot of great feedback. If the data was mission critical Postgres would likely be my other choice (pending app use cases) because it’s had decades to mature.

3 Likes
4

Given that Postgresql doesn’t have a built-in replication mechanism and one needs to setup an extension and configure it, how would you prefer to use it exactly? Not a troll question, I am genuinely curious if you just name Postgresql as a possible easy-to-use solution, or you have an experience using it.

For RethinkDB, for me, it has the same value as MongoDB. i.e. projects of similar length of development (RethinkDB arguably had even less resources to develop a good database) and similar stable features.

2 Likes
5

Yea I’ve never done a PG replication for production… i’ve always had a cloud service handle hosting and configuring.

I mostly named it as a more robust alternative (than Rethink, Mongo, etc) from other peers who handle lots of data with it. For me using PG is much more cumbersome than using modern NoSQL databases. I don’t really have a lot of experience with it. I’m running 1 backend for a smaller mobile app with it at the moment and have tinkered with it on side projects.


[quote="slava, post:4, topic:9736"] For RethinkDB, for me, it has the same value as MongoDB. i.e. projects of similar length of development (RethinkDB arguably had even less resources to develop a good database) and similar stable features. [/quote]

Yep that’s a valid point! Mostly the shift in switching from Mongo in the first place is because of losing clients, brighter outlook, (1st class realtime, joins, atomic transactions, hindsight from other NoSQL DBs, etc.)

Mongo does have more resources, and I think that’s what will keep them afloat and going. I do think they can work through any issues they may or may not have.

6

heh, sounds like you aren’t really using much of meteor anymore,

Not quite sure what your post is trying to say, feels to me you are saying you are wanting to build your own opinionated stack with all the stuff you like. Which is cool.

1 Like
7

Bad news. You are my leader. I was trying to follow you. I think you will quit meteor too.

8
9

Sorry, I didn’t understand: what’s wrong with MongoDB?!

6 Likes
10

From a newbie’s point of view I also am curious what’s bad about mongo. You read a lot of bad stuff about mongo but you can’t really see any objective comparisons. When you see lots of coders just hating without giving thorough arguments I don’t know whether or not to take it serious or not.

11

Unfortunately this is true for most framework and tools. Developers are biased as their experience with one tool is far larger than with a new one. They often see one paradigm and when someone challenges it, they’re scared of change, learning something new or potentially losing their jobs since they don’t know it and instantly get their spikes out.

I can not stand evangelists. Frameworks and platforms are tools to perform a specific task. You use a screwdriver on screws and hammers on nails. I can definitely get a nail in with a screwdriver, but I prefer the one that’s right for the job. Plus you might get to learn something new!

3 Likes
12

I dont think this is something tragic, we all know that Mongo sharding is not perfectly secure (from data consistency point of view in case of node crash ) in default configuration. And using it as kinda NoSQL Redis to track something real time is one of the approaches.

Sometimes I think that keeping all in SQL and polling some joins from it to Mongo is the way to go for us. I mean like for every user view we have some master document which should have all data user need to see on his screen.
Doing it using reactive joins in mongodb could be quite DB heavy. But if we offload this to SQL and on meteor DB operation sub-app we just poll these sql joins and apply diff to our mongo, it can end up creating nice denormalized document collection which is up to date with SQL data and it can be even reactive observed from end user point of view.
And every view from user will not trigger cascaded queries, as if we use some mongo joins reactive packages.

13

For those who want to know more about Mongo’s shortcomings, this post has a quick summary: Why You Should Never Use MongoDB

That being said Mongo shouldn’t always be ruled out. It has its place to be sure, but from experience I’ve found that place to be in quite a few more places than expected. A few quick tips based on past experience:

  1. Mongo is really easy to get started with, but if you’re putting a serious app into production (and you’re not already a Mongo specialist), host your Mongo DB with pros. Right out of the gate companies like https://compose.io get you up and running with a high availability replica set (multiple data nodes, backups members, etc.). Getting this stuff right can be a real pain so if you’re worried about data loss outsourcing your Mongo DB environment can take some of the stress off.

  2. (I almost consider this to be more important than #1) Make sure you understand Mongo WriteConcern’s. Understanding write concerns helps mitigate a lot of the risks outlined in the often linked to Call me maybe: MongoDB stale reads article.

4 Likes
14

Prefer if posts include facts to support their argument. It is a waste of everyone’s time reading otherwise.

5 Likes
15

Mainly I just want to see how many others are running another DB as their primary. I really don’t want to roll my own stack again… I wish Meteor was a bit more configurable/modular.

Don’t do that because of this! :smiley: I think using Mongo makes sense in many applications, understanding some of the Mongo quirks is all that’s needed to use it safely IMHO.

I’m still using Meteor but not in the normal way. I’m betting that RethinkDB will have 1st class reactive support in the near future which is why i’m starting my new personal app with it. Swapping out is just a quick find/replace on the server and a little fiddling with how Redux updates it’s data.

Thanks for the article links! I also updated my top post to include them (I guess I assumed everyone had read them already). +1 on #2

Links added to the top post. Also just to clarify my argument/choice for not using it was based on losing customers because of their opinions of MongoDB.

Just wondering are you doing this currently or is this just a thought/plan? It sounded like the latter but wasn’t sure.

16

I’ve never been a huge fan of mongo. It seems like it was made for a specific use, but since it works well with javascript, has been extended way past its normal use in a strange and clunky way.

Some problems I have with mongo:

  • Best practices often seem unclear where they are very clear with SQL
  • Data integrity is too easily lost
  • Working with arrays can often be fairly annoying or act in strange and unexpected ways. It’s easier to use joins

My favorite is posgres, personally.

2 Likes
17

I’m very curious with RethinkDB, how are you using it? Shortcoming compared to Mongo? Upsides etc? Joins would obviously be awesome, currently doing joins server-side which is terrible slow…

1 Like
18

Just a thought/plan for now. We are half way doing something like that in mongo itself - using normalized data as base data model our backend is using. And than running cursor.observe on these and changes are reflected into user facing denormalized collections.

But still there is a lot of data which is not worth to be prepared this way and need to be generated only when requested.

1 Like
19

To offer a data point contrary to this thread: I’ve had clients seek me out because we have Meteor experience.

It’s been repeated several times, and is the platform of the OP’s argument, so I’m surprised nobody’s brought this up:

You say you’re ‘losing clients’ because of Mongo.

You either have incredibly well-informed clients who know what they want…or incredibly reactive ones who read an article once, heard you work with a “Mongo-based stack”, and went elsewhere. That seems like an arbitrary way of selecting. Would they have been open to it if you addressed their concerns? Or were they just…“Ew! Mongo! No!!!”? That seems odd.

I sling code from time to time, but am also focused on the business side. Can you go into more detail on how they explained it? Are these big, enterprise clients? Startups? In a particular space? Is there legacy data?

There’s something I’m not getting about the whole “It’s my clients” thing.

5 Likes
20

I don’t think anyone here chose the meteor/mongo stack because they absolutely had to work with mongodb, and ok we’ll make do with that meteor thing if we have to.

The meteor experience is amazing and game-changing, and if I’ve had to cover for a lack of transactions with some sql tables to be safe, it’s cost me VERY little in dev time or in cost.

But… meteor would be an easier sell with real core SQL support I’ll have to agree…

1 Like
21

People shying away from mongo in favor of arguably more reliable database platforms often don’t have the slightest clue about what can go wrong with those databases.

It is always assumed if it’s sql, it is reliable.

On the contrary, like every other devops task, maintaining a database server is a daunting task, whether or not it is ACID compliant. They do fail and when they do, they fail very miserably.

The most important point everyone is overlooking is the availability paradigms introduced and/or leveraged by these nosql systems like mongodb.

For example, I don’t care about postgresql scaling, most apps will never have scalability requirements, but what they do have from day one is high availability. And there enter us the territory of replication nightmares. Mongodb solves that problem and solves it rather well. I’d rather let go of a couple of database transactions/operations than lose the entire application over a corrupt database instance. And if designed cleverly, any app can recover from some data loss. There are patterns for ensuring this, regardless of the underlying database technology.

Now I’m not saying let’s throw away sql. I’m not in a camp, any camp for that matter. I think every job requires its own set of tools, but for any app job to actually require a specific set of tools, it should foreseeably be bound to grow in scale. And that’s a very unlikely scenario for 99.999% of the apps out there. If your app fits that top-notch percentage, I’m sure you’ll figure it out using the millions of venture $$$$ they’re throwing at you.

Sql has its place with strict transactional requirements like finances where damage may be irrecoverable. And mind you, I don’t actually place ecommerce in that realm. A lost order is always recoverable. (Ok, there of course are cases where transactions are favorable, even irreplacible for ecommerce) My point is, we are usually over-sensitive about our data and overlook our actual requirements.

In my opinion, meteor saves us enough development time, we can spare some time to develop application-level transactional capabilities where it does matter in the app. Otherwise, the cost-benefit of the isomporphic api, imho, far outweighs the vaguely-potential loss incurred by data discrepancy, should it ever occur.

11 Likes
22

Sure. All of my clients so far are startups with greenfield projects and so far have been in the SF bay area. The issue comes up when they ask what i’ll be using to build their app, then they have a mentor or friend go over all the stack as well as how/where it will be hosted, etc…

It usually goes something like “well my friend is a programmer and he said X & Y about MongoDB and that it’s risky to use it”. From there it’s usually hard to convince them that Mongo will be ok for their app.

+1 :thumbsup: I also don’t think that Rethink is a panacea either… however for document databases it seems to have one of the best feature sets.

I also think a lot of the potential Mongo problems can be avoided by using a good database hosting service.

I totally agree with this. A lot more can be done at the app level. For me the isomorphic API for the database is nice (and I would love to have ReQL in the browser!) but it wouldn’t trump better data consistency if the app needed it (a photo sharing site most likely does not!).

Checkout this video https://www.youtube.com/watch?v=05R-TDP0Ltc for a preview of RethinkDB for Meteor. The package is not production ready but it’s really slick! It even has a partial clientside mini-rethink. I’m currently using a rethink driver with the MDG promises polyfill. You can also use Futures if needed. I’m not sure how stable the meteor-rethink package is for just the server but from light testing it seems to be stable (it’s mostly just wrapping async methods with fibers and monkey patching).

1 Like