Ever wonder what would happen to an open source database project in case its main developers “get hit by a bus”? Or less dramatically, if they leave the project completely. That’s what the “bus factor” (also called “truck factor”) measures: how many people would have to disappear before no one left knows how to fix or update specific parts of the code.

I’ve been messing around with a tool called the Bus Factor Explorer by JetBrains to explore the associated risk in some of the most popular open source databases. I looked at six of the big ones to see where they stand. Here’s the current baseline (March 2026) according to this tool:

For example, for MongoDB to “hit a wall”, 7 devs would have to leave the project. For MySQL, PostgreSQL, and SQLite, if 2 devs leave, the project is at risk of stalling. Of course, this is just one factor; there are other factors that influence the continuation of open source projects, but this is still an interesting insight you can take into consideration when choosing a database.

The tool has a categorization according to the project’s bus factor (a baseline that can be adjusted in the tool if you want):

• ✅ OK: 5 or more (MongoDB, MariaDB, Redis)
• ⚠️ Low: 2 to 4 (MySQL, PostgreSQL, SQLite)
• 🔴 Dangerous: 0 or 1 (N/A)

I also used the tool to see what happens to the root directories (the functional parts of the code) if you start unchecking the top contributors to each project. Specifically, I wanted to see the proportion of directories that would be “lost” if the top one or two contributors left the project. I ignored the individual files at the root level. The results look like this:

Here, a lower number is better (fewer directories impacted). So, Redis is pretty strong in this simulation as no directories would take a hit. On the other end, we have MySQL and SQLite with 100% of their directories potentially left unmaintained if the top two developers leave. PostgreSQL would lose 83% of its directories in a similar situation. These were the big surprises to me, although all this is aligned with the fact that they have a low bus factor (high risk) of 2.

MariaDB did pretty well, especially when compared to MySQL, which supports what I have been trying to say about how MariaDB is much more than a fork of MySQL in my articles and talks (see this, and this, if you are curious).

You should not rely merely on “bus factor” risk assessments. This is useful in mission-critical situations or when comparing projects that are even in other metrics that you might be using to compere and evaluate them. Here are some other aspects to look at:

• Corporate Backing: Does the project have large companies behind it? Even if a lead developer leaves, the company is likely to hire someone else to fill the gap, ensuring continuity.
• Community Activity: Look at the number of active issues, pull requests, and discussions. A buzzing community can often sustain a project better than a few silent experts.
• Documentation Quality: Comprehensive documentation ensures that knowledge isn’t locked in someone’s head, making it easier for new contributors to onboard.
• Licensing: Ensure the license fits your use case, as this impacts the project’s long-term viability and adoption. For example, a GPL-licensed project doesn’t allow anybody to distribute a closed-source application based on it, hence the project is future-proof as far as licensing goes.

I investigated the bus factor of other open source projects that I’m a big fan of, like MyBatis, Vaadin, and others, but I’ll let you do your own findings with the tool. Let me know if you find something interesting!

This appendix lists every directory and file at the root level that drops to a Bus Factor of 0 in the simulations.

• With 1 dev gone: .bazelrc.local.example, .gitattributes, .prettierignore, MODULE.bazel, distsrc, etc
• With 2 devs gone: All of the above, plus bazel, buildscripts, jstests

• With 1 dev gone: VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian
• With 2 devs gone: VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian

• With 1 dev gone: None
• With 2 devs gone: None

• With 1 dev gone: mysql/mysql-server (root meta), iwyu_mappings.imp, config.h.cmake, CMakeLists.txt, libmysql, mysys, client, components, strings, mysql-test
• With 2 devs gone: Virtually all project directories (36 total), including storage, sql, router, extra, plugin, utilities, etc.

• With 1 dev gone: COPYRIGHT, meson_options.txt
• With 2 devs gone: Virtually all functional directories (23 total), including src, contrib, doc, config, interfaces, etc.

• With 1 dev gone: VERSION, manifest.tags, make.bat, manifest.uuid, configure, README.md, mptest, main.mk, Makefile.msc, doc, manifest, tool, src, ext, test
• With 2 devs gone: Virtually all project boxes (28 total), including root-level scripts and all core subdirectories.

Enjoyed this post? I can help your team implement similar solutions—contact me to learn more.