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

Planet Earth
1

I’ve stopped using MongoDB in all new projects. I really don’t feel comfortable using Mongo in production anymore… It’s hard to tell how valid all the recent bashing PR is.

I mean if you could pick any database today… would it be Mongo? For me RethinkDB and Postgres are my top picks.

It’s also very hard to sell a client on data integrity with MongoDB in their stack now. I either have to turn down clients, roll my own stack, or cut out Mongo from Meteor. Losing clients is my largest problem… I haven’t lost any data that I know of but it’s hard to say for sure.

Has anyone else ran Meteor without Mongo as the primary database? I’d love to hear about your setup
I have two Meteor apps now running RethinkDB. One without any Mongo (microservice cluster with REST API and SMS auth) and another with Mongo only handling user IDs.

My current strategy is to use Mongo for user accounts and only use it for storing the user id so it can be used to authenticate and allow for easy user create/logins.

Then use any other database on the server (easy with promise enabled drivers) and fetch data from the client with via Meteor methods.

Publications are replaced with a Meteor method with the same signature. It returns the same data that the publication would return. The only difference is that now the client has to manually call it.

However, with Redux this isn’t as big of a deal as it was 1 or 2 years ago. It’s fairly easy to keep track of state and do optimistic updates. To get a reactive UI you just need to long poll the client.
Most apps don’t need tight realtime so long polling ever 30 seconds or min is usually more than enough.

Long polling for 80% of the app may even be more efficient at scale??

If you need a tight real-time feed the ccorocos:anydb package will let you setup a subscription feed without any clientside stuff.

I really hope I don’t need to keep swapping out parts of Meteor to keep up with the industry standard… I love Meteor I just wish it wasn’t constantly 6mo. behind everyone else :confused: Once async/await and Falcor mature it’s going to be hard to choose which stack to use.

edit
Links to articles that caused the mongo upset (note i’m not giving up on Mongo because of these, the articles were the start of ‘panic’ that’s causing clients to not want Mongo in their stack):

Call me maybe: MongoDB stale reads
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/

9 Likes
2

Well do you agree with your clients? what if you are building an app for yourself?

1 Like
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