Over the last three years, the reach of the Community Health Toolkit (CHT) has grown 340%, from supporting 40,000 community health workers (CHWs) to equipping over 180,000 CHWs across 24 countries by the end of 2025. What started as a simple SMS pilot in Malawi has become a critical component of national health systems, guiding health workers to provide high-quality care to millions of households and generate data that governments rely on to make life-saving decisions.
This level of scale is not accidental. It’s exactly what the CHT was built for: the result of 15 years of catalytic vision and collective effort from a global ecosystem of implementers, governments, and partners.
But scale brings its own demands. More CHWs using the CHT means more moments of digitally enabled care are delivered, and, in turn, more data records are generated, stored, and managed. Every household visit, every follow-up, every referral creates an entry in the system. Multiplied across 180,000 health workers and millions of care interactions, the technical demands grow rapidly. This is what scaling any system looks like – and these are exactly the kinds of challenges we’re excited to solve.
Across these same large-scale programs is where the most honest technical conversations are happening right now in our community: about storage costs, hosting infrastructure, database performance, and long-term sustainability under local ownership as we increase scale.
What we are hearing from the CHT Community of Practice
We have listened carefully, and the community’s priorities have come through loud and clear:
These are important questions. Scale, total cost of ownership, and technical choices are all connected.
As adoption accelerates in 2026, now is a valuable opportunity to take stock of the lessons we’ve learned, what we’ve already improved, and how we are future-proofing the CHT, together.
Built for the last mile: the CHT's architectural choices
The CHT was designed from the ground up to solve one of the hardest problems in digital health: making software work reliably for CHWs in areas with intermittent or no connectivity. Regardless of whether or not they are connected to the internet, a CHW in a remote area should be able to open the app, see their patient list, submit a form, and have that data sync reliably to the server when they are back online.
CouchDB and its mobile counterpart, PouchDB, make this possible through bidirectional sync that keeps data consistent between the device and the server, even under unreliable network conditions. This offline-first capability is not a nice-to-have; in many contexts where the CHT is deployed, it is the difference between a system that works and one that does not.
At national scale, however, CouchDB comes with tradeoffs. Every time a document is updated, CouchDB keeps a copy of the previous version until a cleanup process, called compaction, removes it. At large scale, with millions of documents and tens of thousands of users, this creates storage overhead and puts pressure on the system during cleanup cycles.
Importantly, the majority of storage costs in CHT deployments do not come from the actual health data itself, but from indexing structures and the space provisioned to handle upgrade and compaction cycles safely.
That is where the most impactful near-term improvements are focused.
What CHT 5.0 has already delivered
CHT 5.0, released in November 2025, brought several major improvements.
The adoption of CouchDB Nouveau replaces the legacy full-text search indexing system. This alone reduces disk space usage by up to 35%. In real-world deployments, early 5.0 upgrades resulted in 5-25% disk savings, depending on instance size and usage patterns. That is exactly the kind of result we were building toward.
CHT 5.0 also significantly improves document replication, the process that keeps devices and servers in sync. Synchronizations complete faster, server load per sync cycle is reduced, and the same hardware can handle more concurrent users with just a software upgrade alone and no additional infrastructure changes. Historical replication backlogs and the constant firefighting that accompanied them have been largely resolved.
Combined with improved operational tooling – including CHT Watchdog for monitoring and alerting, and Kubernetes-based deployment – national-scale deployments across many instances are now more manageable than they were even two years ago.
The future of the CHT: A more flexible foundation
Evolving the CHT architecture
We are actively evolving the CHT’s architecture by progressively developing cht-datasource, an abstraction layer that separates application logic from the underlying database.
This means that instead of application code talking directly to CouchDB, it talks to a clean, versioned API. That API sits between the application and the database, enabling the underlying storage engine to be adapted or added to without modifying application or configuration code.
CouchDB is not just a database choice; it is integrated into how offline sync works, how document revisions occur, and how certain metadata databases are maintained. Replacing it would therefore require significant engineering to not only establish a different database but also a new sync mechanism.
The cht-datasource abstraction layer is progressively creating the right conditions for technical stack evolution without a full rewrite. This approach reflects the ethos of the CHT and its community: careful, incremental, and validated against real deployments.
Driving storage costs further down
A key distinction to understand is between space actively used by data and space provisioned to handle upgrade and compaction cycles safely; the latter is currently the larger contributor to hosting costs. CHT 5.0’s Nouveau significantly reduces disk space used by search indexes. Work is already underway to reduce the provisioning overhead – the space that needs to be reserved rather than the space actively used by data.
Early results are promising and we expect to share concrete findings with the community in the next few months.
Exploring complementary database technologies
We are actively exploring PostgreSQL as a complementary relational database within CHT Core to take over workloads that a relational database handles better: analytics, interoperability, and server-side data access for online users. Early findings suggest that a dual-store approach could make storage overhead more manageable, as relational table storage is significantly more compact than CouchDB’s JSON document storage.
More practical data lifecycle management
We are also closely tracking improvements to purging in newer CouchDB versions, which could make it more practical to manage the data lifecycle within active instances: archiving historical data no longer needed for day-to-day operations while keeping it accessible for analytics through existing tools like CHT Sync.
The roadmap
How can you help shape what comes next?
The CHT is only as strong as the community behind it. We’re not building this alone – we’re building it with you. Here is how you can help us move faster and better, together:
- Share operational data. Performance metrics, storage utilization trends, and sync reliability data from deployments help us identify bottlenecks and validate improvements. The more we can see, the better we can build. CHT Watchdog can provide valuable operational insights, including server and client Apdex scores.
- Help us build the cost evidence base. If your organization tracks hosting or infrastructure costs for national-scale digital health systems, sharing the data you are seeing helps us build a clearer picture of what sustainable CHT hosting looks like and strengthens the case for investment.
- Engage on the roadmap. The CHT roadmap is public and open for community input. If there are priorities or use cases you think should shape the database abstraction work or the TCO roadmap, we want to hear them.
Behind every storage metric and database decision is a community health worker who depends on their app to work, and a government that needs a system it can own and sustain. That is what drives this work, and we are glad to be building toward it together.