Why change v8 to spidermonkey in mongodb js engine?

Welcome to the MongoDB Community @anlex_N!

There is a lengthy article in the MongoDB Engineer Journal which explains some of the technical reasoning: Code-generating Away the Boilerplate in Our Migration Back to Spidermonkey.

This paragraph from the article provides a nice summary:

SpiderMonkey has several qualities that make it the most suitable option for our needs. Most importantly, its process model is most like ours, with a single process for the browser and threads for tabs. This necessitates better tools for constraining memory and managing resource exhaustion. In addition, Firefox (and thereby SpiderMonkey) is available on the greatest number of platforms. In addition to its high performance JIT, it also has a baseline interpreter in C++ that ensures that any architecture capable of hosting a reasonable distribution of Linux can also run Firefox. And as icing on the cake, the Mozilla Foundation offers extended support releases of Firefox that offer security fixes for a year; annual maintenance affords us a substantially more manageable integration than the six-week fix cycles we had with V8.

From an end-user point of view, the choice of JavaScript engine affects two broad usages: client-side and server-side. The legacy mongo shell is part of the MongoDB server codebase, so a given release of MongoDB will have the same embedded JavaScript engine in both of these binaries.

Server-side JavaScript is generally discouraged (and often disabled) as there are significant security, concurrency, and performance caveats. The MongoDB query language has expanded in successive server releases to replace the majority of use cases where JavaScript would previously been required. The server-side eval command (db.eval() via the mongo shell) was deprecated in MongoDB 3.0 and removed in MongoDB 4.2. The limited contexts where server-side JavaScript can be used are not expected to support the full range of language features (or pace of change) as Node.js.

However, for the client-side use case we have introduced a new MongoDB Shell (mongosh) which is built on top of the Node.js REPL. The new MongoDB shell is designed to be embeddable and extensible. You can install mongosh as a standalone download, but you’ll also find mongosh embedded in MongoDB Compass and third party tools (for example: JetBrains: Introducing MongoDB Shell in DataGrip).

That’s a rather long explanation, but if you’re a fan of Node.js you should definitely check out mongosh and let us know if you have any feedback: How can we improve the MongoDB Shell?.

Regards,
Stennie