NOTE: Forcing MongoDB 5.0 Changes Minimum Requirements (Will Require AVX Instruction support).

[LeeThompson]

I'm not sure if RocketChat is aware that MongoDB 5.0 and greater requires a CPU with the AVX instruction so I'd like to make sure the team is aware of the ramifications of dropping MongoDB 4.4 support with the next major release of RocketChat (and is in a depreciated status with RocketChat 6.x).

RocketChat's documentation seems to pride itself on running on minimal hardware but this change to requiring MongoDB 5.0+ will be cutting off many inexpensive devices.

In my own use-case, I run RocketChat for my family and a few friends, 10 users tops with most use from 2 people and a bot. It's running on an older Synology DS1817+ model in a docker container along with MongoDB (also in a docker container). The DS1817+ uses an Intel Atom C2538 CPU which does not support the AVX instruction and thus will be unable to upgrade to MongoDB 5 and also RocketChat 7.

While I may upgrade to a newer Synology model (while I could afford it, they are not trivially cheap), at this time my only reason to do so would be to run RocketChat 7 and, to be honest, I am far more likely to stay at the final RocketChat 6 - or look for an alternative and I want to bring this to the RocketChat team's attention because I am probably not the only person in this boat.

The Intel Atom C2538's procinfo (NOTE: there are 4 cores so this repeats 3 more times with a different processor number, I've omitted those for brevity.) Not the most amazing CPU but it still does the job, except for MongoDB 5+.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 77
model name  : Intel(R) Atom(TM) CPU  C2538  @ 2.40GHz
stepping    : 8
microcode   : 0x121
cpu MHz     : 2400.000
cache size  : 1024 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 11
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch arat epb invpcid_single tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bogomips    : 4800.19
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

References

MongoDB

The MongoDB Production Notes document almost hides the new requirement near the top of the current production notes.

MongoDB 5.0 requires use of the AVX instruction set, available on select Intel and AMD processors.

Notes

• Edited to include references and improved clarity.

[serviceman]

I am in this boat too. I would have to change the server that I'm using. I probably could do that, but it would be a pain with unknown benefits of doing so.

[marcotrevisan]

I had your same issue. My system is a debian bullseye in a Proxmox LXC container. Used the mongodb-org repository i.e. http://repo.mongodb.org/apt/debian/dists/bullseye/mongodb-org/5.0/main/binary-amd64/ .

The cluster's host is an Atom C2758 low consumption system, useless to say I'm not planning to change hardware just to upgrade an open source NoSQL DBMS that decides to change architecture from one release to another. By the way, I'm not even sure this is in line with the most basic Debian repository rules: if you build a package for amd64 then it must execute on any amd64.

That said, I solved my issue by compiling Mongo from source (following the directions here: https://github.com/GermanAizek/mongodb-without-avx and in mongo's repo itself), replaced the binaries from the incorrectly labeled -amd64 packages and it just works.

If you do the same, make sure you checkout your required release tag (i.e. "r5.0.20", in the mongo subfolder) before building. Also, you may want to use the following build command: python3 buildscripts/scons.py DESTDIR=/opt/mongo install-devcore --disable-warnings-as-errors --separate-debug

Hope this helps

[LeeThompson]

I think RocketChat needs to take a hard look at this choice.

In my situation, compiling my own Mongo from source would be very difficult.

1. I'm running Mongo in a container, I have no idea how to make my own image. I'm sure, given time, I could figure it out but I'm not sure if it would be worth it.
2. My workstations are all Windows so I'd have to cross compile or use WSL to build it (with all the various perils involved).
3. If something goes wrong, I'd be kinda stuck.

[blackcj]

I'm in the same boat. I have an Asustor NAS and Asustor still doesn't even sell hardware that supports AVX. There are very few NAS devices that support AVX and NAS servers are the most affordable option for home servers. I'm going to attempt to compile mongo from source in a docker container but if that doesn't work, I will need to look for alternatives. Please consider keeping the mongo 4.4 support or adding support for other database solutions (e.g. Postgres).

[peschmae]

Please take this to heart

We're running a rocket.chat instance for our scouting group, and rely on companies sponsoring our hardware that we can run a few VMs on. Today when I updated a few tools, I realised we're stuck on an older rocket.chat version and that's when I came across this issue.

I've now created at least a newer snap, with rocket.chat 6.x and mongodb 4.4 (as long as it's supported), but there's no way we can move to mongodb5+ due to their AVX requirement, without finding someone that sponsors newer hardware.

[boinappi]

I have a similar scenario like OP. I host a rocketchat instance on a Diskstation DS920+ without AVX support for family and friends for private IM. I already figuered the mongo-avx-diskstation issue out in december 22 and brought this issue to attention in the RC forums - with no response.

While digging into this, i found the following possible solutions:

1. host the database on a machine with avx enabled cpu
2. use MongoDB Atlas/db cloud service
3. compile MongoDB without AVX support (https://github.com/GermanAizek/mongodb-without-avx)

My preferred solution would be 3. Ideally packed nicely in a preconfigured docker container for the Synology ecosystem. I guess it would be neccessary to cross compile, which has many pitfalls along the road. The good news is: It seems to be possible, and there is a growing demand.

Also the RC forum has a growing number of threads about this.

[blaine07]

Here to say the same; really enjoy using RocketChat and this AVX limitation stinks.

[machines-github]

I need to add my 2 cents here too: My situation: Shoot a cheap VPS for ~3 bucks a month with 2GB Ram, so perfectly enough for small Rocket Chat for Family&Friends. As a newcomer to Rocket Chat and similar self hosted Chat Applications I spent a good 10 hours all in all trying to get it to run with (first with docker rootless) then Docker and researching. The not so up-to-date documentation does the rest. I really thought i might lose my mind, Docker easily played with Apache and stuff and this thing just didnt worked. Finally I tried to install it over snap and there it revealed its MongoDB AVX/AVX2 dependency and refused to install :/ So rn Im not sure what to do, probably the only possible thing is to look for another hosting but thats just bad now, and I dont want to host it in my home for various reasons and it could had be so perfect.

So rn I cant use it. :/

[marcotrevisan]

There's another viable option: using FreeBSD. You can build MongoDB (5.0, 6.0 or 7.0) from the ports tree. It's as easy as doing "cd /usr/ports/databases/mongodbX.Y ; make install clean". You'll be prompted with a text menu and be able to check the option to build without AVX (the option is unchecked by default). It will take care of the needed dependencies and build those ports too. Then you may use that system as a local db server (or you may install Rocket.Chat over there too and do everything with a single BSD system). I think this is the safest way to deal with it using "normal" hardware, FreeBSD's ports tree is trusted stuff. They already checked everything for you, you only have to "make install".