💾 Questions about MongoDB hosting, MongoDB license changes, version support, Meteor 3?

Hello!

I noticed recently that my hosting provider (the otherwise impeccable scalingo.com) won’t provide MongoDB hosting for MongoDB Versions 7 or 8.

Now that’s kind of sad because switching to MongoDB Cloud (Atlas?) would probably lead to a much higher latency with our server side code, publications etc, if it’s not colocated in the same environment anymore?

→ So, my questions:

  1. What is / are the supported MongoDB versions for Meteor for now & going forward?
  2. Is it possible to self-host MongoDB using a docker image(without a lot of security, backup, update etc overhead)? Is the community edition samesies, feature-wise, if we look only at the pure Database features as the Enterprise offerings?
  3. Anything else we could do to keep our users safe & ourselves out of the MongoDB hosting business?

So maybe now I understand better the discussions about alternatives / API-compatible layers like FerretDB (any experience with this?)

And Redis too, which also seems to have switched to a new licensing scheme…

  1. Will Galaxy still support hosted MongoDB going forward?

Any other ideas / plans going forward? How are you going to handle MongoDB hosting going forward?

Thank you everybody and keep on playing!

1 Like

Is you project deployed in France for France?

Hi, yesno, it’s deployed in France for the German/Austria/Switzerland area, so it’s close enough & still in the EU, which is also cool from a data protection angle.

1 Like

Ok, I noticed Scalingo only has 2 regions, both in France. When you run MongoDB Atlas with AWS, you have an available region in Paris: eu-west-3.
I don’t know how complex would this be for you and what is the cost difference but technically you could deploy everything in Frankfurt in AWS (eu-central-1) and have the Atlas MongoDB cluster added into your AWS VPC with your Meteor servers. Can’t get faster than that.

1. What is / are the supported MongoDB versions for Meteor for now & going forward?
Meteor uses the Javascript (Node) driver for MongoDB. You can look in the Meteor repo on Github, see the driver version and understand the compatibility with the MongoDB versions. This version is constantly being updated.

2. Is it possible to self-host MongoDB using a docker image(without a lot of security, backup, update etc overhead)? Is the community edition samesies, feature-wise, if we look only at the pure Database features as the Enterprise offerings?
Yes. E.g. Deploy with MeteorUp(mup).

3. Anything else we could do to keep our users safe & ourselves out of the MongoDB hosting business?
Host your own MongoDB

Hi Daniel,
I started with self-hosted, then migrated to Galaxy/Atlas, and 1 month ago we moved our production and staging environments (2 meteor apps and MongoDB) to zCloud.ws.
FYI the owner of zCloud is @filipenevola former meteorjs CEO :wink: the zCloud support team was perfect during the migration (took less than a few hours a Friday afternoon). The selected region is Europe 1 - Germany to serve our European customers (mainly France). The response time decreased by 4 on our biggest aggregates and the cost was reduced by 2 (with higher resources), and we were able to increase transparently the resources to absorb punctual marketing operations (x20 traffic).
If you have any questions, please DM me.

1- We use the Node.js MongoDB Driver, which defines the supported MongoDB versions. From Meteor 2.14, the driver version is 4.17.2, fully supporting MongoDB 6.0 and offering partial compatibility with MongoDB 7.0. We plan to stay as close as possible to the latest MongoDB versions.

2- The main differences between the Community and the Enterprise Edition are security features, analytics integrations, and operational tooling, rather than core database features. If you self-host, you need to take care of those things. But soon you will be able to use Galaxy and not worry about those.

4- Set for May (announcement coming soon), Galaxy will offer full MongoDB support :tada:, enabling you to run the latest MongoDB versions. You won’t have to worry about self-hosting complexities, as the Galaxy team will set up everything for you.

We also plan to offer FerretDB, but that’s still in the early stages.

8 Likes

Hello Guys!

Thank you for your great explanations.

@fredmaiaarantes congratulations on the coming full MongoDB support in Galaxy! Looking forward to see that!

Diving into your answers & doing some structured googling myself, I arrived at the following status & answers for my current questions:

  • What are the currently still supported LTS releases of MongoDB which can be freely hosted by 3rd party hosters? Are there any left?

From the MongoDB Licensing FAQ:

What is the new license called and what will be licensed under it?

The new license is called the Server Side Public License (SSPL). All MongoDB Community Server patch releases and versions released on or after October 16, 2018, will be subject to this new license, including future patch releases of older versions.

That means we (our company with our current hosting provider ) are stuck on 4.0.16 or there roundabouts (which is what we’re running on right now), with no future updates / patches / nothing more coming down the pipe with the previous license.

And to answer my own, second question: Which MongoDB major versions will Meteor 3.x support going forward?

Looks like the MongoDB drivers are generally pretty generous / effective in offering backwards & forward compatibility, looking at this compatibility matrix (current version right now is v6.5.0).

Thank you guys for your impulses & let’s enjoy this fine day! Greetings everyone!

1 Like

Are you offering MongoDB as a service?

I did not read the entire license, but my understanding is that if your answer to the question above is “no,” then you can host your own instance of MongoDB, just like how you used it before the license change.

Hi @rjdavid !

No, we’re not offering MongoDB as a service, but our hosting provider does / was doing it… so we had everything colocated & very fast from a network access perspective, where we wanted it.

Also I’d rather not have to deal with setting, updating & especially backupping this up all by myself - a cluster of instances too for failover etc? - Too much room for errors, and I don’t want to lose any mission critical data while i’m dabbling with some configuration settings etc.

→ It’s just not our core focus right now, and we need good quality hosting.

Or am I overthinking it? How simple or complex do you (not only you @rjdavid , but everyone) make this?

Are you hosting on one machine? Multiple machines?

Docker or “on the iron”? Same machine as your Meteor server?

One MongoDB instance or multiple ones?

Backups?

MUP or Manual?


Bear in mind that we also have multiple environments / instances of our app running. Not a lot, but currently 3 demo / dev environments, and one live environment.

Irrespective of what your host is doing, if you are “self-hosting” your instance of MongoDB (i.e., you are not paying your host to manage your MongoDB for you), then it should not be affected by the change in license.

I am just answering the question of “self-hosting” from your initial post.

Hi, thank you @rjdavid , indeed our hoster is offering hosting packages with certain “extensions” to be added to the different app instances, like different hosted database options, which are basically “1-click-installs” and then managed for you.

If scalingo provides mongodb 6 hosting, what then is the reason to be stuck with Mongodb 4?

Hi, no, they’re supporting only v4.0.16, the 6.5.0 is the current version of the node mongodb driver.

Got it. My assumption was based from your initial post.

The newer license doesn’t prohibit anyone from offering MongoDB as a service. It just enforces that all supporting software is made public and that is what prevents eg AWS from using it since their internal control planes are closed source.

The newer license doesn’t prohibit anyone from offering MongoDB as a service. It just enforces that all supporting software is made public and that is what prevents eg AWS from using it since their internal control planes are closed source.

That sounds like an easy thing to do in theory, but in practice, “open sourcing all parts of the offering so that others can run it the same way” might mean a lot of custom software for smaller hosters having automated many of their systems & created their own dashboard, interfaces, deploy scripts etc.

Just having that all documented & kept updated at all times would mean a major switch of operations. This isn’t something you just do to please one license for one database, if it’s not inherently aligned with the companies strategy.