SQLite is the most widely deployed database engine on the planet. It runs on billions of devices, from smartphones and browsers to embedded systems in cars, planes, and industrial controllers. Its core team, however, is roughly three full-time committers, and every significant change goes through one person: D. Richard Hipp, who has been writing SQLite since 2000. That is a bus factor of one. If Hipp were hit by a bus, the project would not immediately die, but its future would be uncertain. The merge queue is short, but the fragility is real. Yet SQLite persists, and it persists because of money. Not donations, not goodwill, but contracts, support fees, and a funding model that treats maintenance as a feature worth paying for.

The Merge Queue Is Shorter Than You Think

SQLite's development model is deliberately conservative. The core team is small, and the commit rate is low compared to projects like PostgreSQL or Linux. A quick look at the SQLite timeline shows a steady stream of bug fixes and enhancements, but nothing like the constant churn of a large open source project. This is by design. SQLite's philosophy is to be reliable, predictable, and boring. The team would rather reject a feature than risk breaking a million existing deployments.

The bottleneck is D. Richard Hipp. He reviews and approves nearly every change to the core codebase. He has been doing this since the project started. His name appears on the majority of commits, and his judgment shapes the project's direction. This is not a criticism; it is the reality of a project that values stability above all else. But it means the bus factor is effectively one. If Hipp were unavailable for an extended period, the project would struggle to move forward.

The small team is sustainable because SQLite's scope is narrow. It is a single-file library with a well-defined feature set. It does not aim to be a server, a distributed database, or a data warehouse. It does one thing and does it well. This focus allows a small team to maintain a high bar of quality. But it also means that the project's resilience is tied to the health and availability of a handful of people.

Contrast this with projects like SQLite write-ahead logging, which has outlived the engineering org that chose it. The technology can survive individual decisions, but the project itself needs continuous care. That care is expensive, and someone has to pay for it.

Money Flows Where Maintenance Is a Feature

SQLite is in the public domain, which means anyone can use it without paying a cent. But the project is not free labor. D. Richard Hipp and his team earn a living through a mix of consulting, support contracts, and custom development. They have clients in industries where reliability is paramount: airlines, banks, and device manufacturers. These clients pay for priority bug fixes, custom builds, and the assurance that someone will answer the phone when something breaks.

This funding model is not unique to SQLite. PostgreSQL, for example, has a similar ecosystem of companies that employ core contributors. These companies sell support and consulting services, and they fund development because their business depends on the database being solid. The difference is that PostgreSQL has a much larger community and a more distributed governance structure. SQLite is more centralized, which makes the funding model more direct.

The money that flows into SQLite is not a donation; it is a transaction. Clients pay for a service: the service of having a maintainer who is accountable. This creates a different dynamic than a purely volunteer project. When you pay for support, you have a stake in the project's success. You are more likely to report bugs, contribute patches, and help with testing. The financial relationship aligns incentives.

This is why SQLite's bus factor, while technically one, is less terrifying than it might seem. The people who depend on SQLite have a financial incentive to ensure its continuity. If something happened to Hipp, the clients would likely fund a transition. The project might not die; it would be resurrected under new management. But that is a risky assumption, and the risk is real.

The Money Dries Up for Unloved Infrastructure

Most database projects do not have this luxury. They run on goodwill, small grants, and the occasional corporate donation. The result is that many critical pieces of infrastructure are underfunded and understaffed. The bus factor for these projects is high, and the consequences are felt when a maintainer burns out or moves on.

Consider the MariaDB Foundation. MariaDB is a widely used database, a fork of MySQL, and it powers countless websites and applications. Yet the foundation has struggled financially. In 2022, the MariaDB Foundation reported a budget of around $1.5 million, a fraction of what commercial databases like Oracle spend on development. It relies on a mix of corporate sponsors and community donations, but it has never had the kind of stable funding that SQLite enjoys. The result is a project that is alive but not thriving. The merge queue is longer, the review process is slower, and the bus factor is spread across a few key people who are often overworked.

Another example is the OpenSSL project, which famously suffered from a bus factor of one or two for years. In 2014, the Heartbleed vulnerability exposed the fact that a project used by half the internet was maintained by a handful of volunteers who were not paid for their work. After Heartbleed, the Linux Foundation stepped in to fund the Core Infrastructure Initiative, which now provides support for OpenSSL and other critical projects. But even today, many projects lack such funding.

PostgreSQL is in a better position, but it is not immune. The PostgreSQL community has a strong culture of contribution, and several companies employ full-time contributors. But the project still relies heavily on volunteer labor. The core team is larger than SQLite's, but the bus factor is still a concern. A single person leaving can create a knowledge gap that takes months to fill.

The pattern is clear: when money dries up, maintenance suffers. Unpaid maintainers quit, and the project rots. This is not a hypothetical; it is the history of countless open source projects. The projects that survive are the ones that figure out how to turn usage into revenue. SQLite has done this, and it is worth understanding how.

Ownership and Contracts Beat Donations

SQLite's funding model is often described as a consortium, but it is more accurate to say that it is a company, Hwaci, owned by D. Richard Hipp, that sells support and services. This is not a non-profit or a foundation; it is a for-profit business. The company holds the copyright and the keys to the project. This ownership structure is unusual in the open source world, but it has proven effective.

Contracts create accountability. When a client pays for a bug fix, they expect it to be fixed. This gives the maintainers a clear priority list and a steady income. Donations, by contrast, are unpredictable and often tiny. A project that relies on donations never knows if it will have enough money to pay its bills next month. This makes it hard to plan long-term development or to hire new maintainers.

The consortium model, where a group of companies pool resources to fund a project, is rare but powerful. It is used by some software foundations, like the Eclipse Foundation, but it is not common for databases. SQLite's approach is more like a small consulting firm that happens to produce a public domain database. The clients are not just donors; they are customers.

This is why SQLite survives while others fade. The funding is not a gift; it is a business arrangement. The clients have a vested interest in the project's success, and they pay accordingly. This does not mean that SQLite's code is better than the code of a volunteer project. It means that SQLite has a sustainable way to pay for the hard work of maintenance.

To illustrate, consider the case of a major airline that uses SQLite in its in-flight entertainment systems. That airline might pay Hwaci an annual support fee of $50,000 to ensure that any critical bug is fixed within 24 hours. For the airline, this is a small price compared to the cost of a system failure during a flight. For SQLite, this one contract might cover a significant portion of a developer's salary. This is the kind of mutually beneficial arrangement that donations cannot provide.

The Hidden Cost of Zero-Cost Licensing

Public domain software is free to use, but it is not free to maintain. Someone has to fix bugs, answer security questions, and keep up with changes in the underlying platforms. This is the hidden cost of zero-cost licensing. The users of SQLite, especially those in embedded systems, often do not pay anything for the database. They just use it, and they expect it to work.

This creates a free-rider problem. The companies that use SQLite in their products benefit from the database, but they do not contribute to its maintenance. They might not even be aware that the project is run by a handful of people. This is a common issue in open source, but it is acute in embedded systems, where the database is a small part of a larger product and the developers may not even know that SQLite is there.

Airlines and banks are different. They are large enough and regulated enough that they understand the importance of reliability. They pay for support contracts because they cannot afford to have their systems fail. They are the ones who keep the lights on at Hwaci. The smaller companies, the ones that use SQLite in a smart home device or a point-of-sale terminal, are the ones who free-ride.

Organizations that rely on SQLite should consider supporting it financially, not out of legal obligation, but because the project needs resources to survive. The next time you see a bug in SQLite, or a security vulnerability, remember that the fix came from a person who was paid to work on it. That person has to eat, and their employer has to pay the rent.

What Your Project Can Learn from SQLite

SQLite's funding model is not the only way to sustain an open source project, but it is a proven one. The first lesson is to make your bus factor explicit. If you are the only maintainer, say so in your README. This transparency helps users understand the risk and may encourage them to contribute.

The second lesson is to sell support contracts, not just t-shirts. T-shirts are nice, but they do not pay the bills. If your project is used in production, there are companies that would pay for a guarantee that someone will fix a critical bug within 24 hours. That is a service worth paying for.

The third lesson is to find one or two companies that depend on you. A single major sponsor can make a huge difference. If you can convince a company that your project is critical to their success, they may be willing to fund a full-time maintainer. This is what happened with SQLite and its clients.

The fourth lesson is to set up a consortium if you can. This is harder than it sounds, because it requires coordination among multiple companies. But if you can get a group of users to commit to a small annual fee, you can create a stable funding base. The key is to offer something in return, like priority support or a voice in the roadmap.

Finally, remember that money is not evil. It is what keeps maintainers alive. A maintainer who is paid to work on a project can spend more time on it, respond to issues faster, and make better decisions. The open source world often treats money as a corruption, but it is actually a lifeline. The projects that thrive are the ones that figure out how to turn their value into revenue.

Looking Ahead: The Bus Factor as a Business Decision

SQLite's bus factor is a business decision. The merge queue is short because the money is focused. The project does not need dozens of committers because it has a clear direction and a clear source of funding. This is not a model that every project can replicate, but it is a model that every project can learn from.

You cannot rely on goodwill forever. The maintainers who work on your favorite open source project are human beings with bills to pay. If they are not compensated, they will eventually move on to something that pays. The bus factor is a measure of how close your project is to that breaking point.

If your organization depends on SQLite, or any other open source project, consider what would happen if the maintainers disappeared tomorrow. Would you be able to fix a critical bug? Would you even know where to start? These are questions that every engineering leader should ask. The answers may reveal that the cost of a support contract is trivial compared to the cost of a prolonged outage.

The next SQLite might not be so lucky. There are thousands of projects that are just as important, but they do not have a business model. They are one bad week away from collapse. The question is not whether you can afford to support them, but whether you can afford not to.