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.
The bus factor ranking#
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:
| Database | Bus Factor (higher is better) |
|---|---|
| MongoDB | 7 |
| MariaDB | 5 |
| Redis | 5 |
| MySQL | 2 |
| PostgreSQL | 2 |
| SQLite | 2 |
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)
Simulating top contributors leaving the projects#
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:
| Database | Directories (total) | Directories lost (1 dev gone) | Directories lost (2 devs gone) |
|---|---|---|---|
| Redis | 6 | 0 (0.0%) | 0 (0.0%) |
| MariaDB | 30 | 2 (6.7%) | 5 (16.7%) |
| MongoDB | 28 | 1 (3.6%) | 7 (25.0%) |
| PostgreSQL | 6 | 0 (0.0%) | 5 (83.3%) |
| MySQL | 30 | 1 (3.3%) | 30 (100.0%) |
| SQLite | 11 | 5 (45.5%) | 11 (100.0%) |
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).
Other important factors when evaluating open source projects#
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.
Investigate your projects and its dependencies#
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!
Appendix: Raw Impact Data#
This appendix lists every directory and file at the root level that drops to a Bus Factor of 0 in the simulations.
1. MongoDB (Baseline: 7 - OK)#
- 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
2. MariaDB (Baseline: 5 - OK)#
- With 1 dev gone:
VERSION,config.h.cmake,CMakeLists.txt,libmysqld,debian - With 2 devs gone:
VERSION,config.h.cmake,CMakeLists.txt,libmysqld,debian
3. Redis (Baseline: 5 - OK)#
- With 1 dev gone: None
- With 2 devs gone: None
4. MySQL (Baseline: 2 - Low)#
- 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.
5. PostgreSQL (Baseline: 2 - Low)#
- 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.
6. SQLite (Baseline: 2 - Low)#
- 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.
