# Offline-First at National Scale

> Four public-sector deployments — a national school meals program, a government retail network, a telecoms field workforce and a social housing repairs operation — and the shared constraints behind them: no network, in-country data, and scale proven before development starts.

- Published: 2026-08-17
- Author: Conrad Hofmeyr
- Category: Showcase
- Source: https://powersync.com/blog/offline-first-at-national-scale

---

A field test of PowerSync for a government project last year covered five schools in a mountainous region in Asia. One school had around 20 Mbps of connectivity. Two ran between zero and one megabit. Two had no coverage at all, and in those the procedure was for a staff member to travel to a location with signal roughly once every ten days and sync from there. Guaranteed local retention for extended offline durations (weeks) was baked into the requirements, so that a missed trip would not cost anyone their records.

Testing ran on low-end Android handsets and on recent iPhones, and the application performed well across all five sites.

Requirements like that are ordinary in the public sector. Connectivity is rarely negotiable, because a government application has to cover everyone within a jurisdiction, including the parts of it where the network has not been built. In-country data residency is non-negotiable. And the user count is derived from the size of the population being served, which means it is known before development starts and scalability has to be demonstrated early on during evaluation.

## PowerSync Public-Sector Deployment Examples

Here are a few anonymized representative examples of PowerSync public-sector deployments:

### A National School Program, Asia

A national education authority is implementing a PowerSync-enabled software application that records daily attendance and meal distribution at schools. The application aggregates those figures up through a regional hierarchy all the way to the national level. It is built in Flutter and runs on Android and iOS devices already owned by school staff.

The upcoming national rollout will involve hundreds of millions of records captured per day across millions of students and thousands of schools.

The team initially intended for senior administrators to sync a single summary table of roughly two million rows, with a target initial sync under two minutes. That target was not achievable at that row count with PowerSync. The workable approach was restructuring: separate aggregated tables per administrative level, so an administrator syncs a few dozen rows per day and a regional administrator syncs under a thousand. The data volume on the wire dropped by three orders of magnitude.

The scale of this project breaks assumptions outside the sync layer as well. The team had been using a commercial hosted identity provider and dropped it once the per-user pricing was extrapolated to a national rollout, replacing it with their own JWT signing. PowerSync is not an identity provider. It verifies JWTs from whatever mints them, which means the identity system each organization already runs.

Accuracy is what a program like this gets judged on, and that is the citizen-facing outcome here. A meal served in a school without connectivity is recorded at the point of service, and it reaches the government as captured data instead of being reconstructed from paper or memory some weeks later.

Parents will eventually get a view of the same records. A parent account will only sync its own children's data, enough to show whether a child was marked present and received a meal on a given day. Parent logins are scheduled for a release after the school-level features that make up the first rollout, and they change the shape of the load considerably. Parent sessions are short, a few minutes each, and they cluster almost entirely between the start of the school day and mid-morning, so the deployment has to absorb millions of brief connections inside a few hours.

### Nationwide Government Retail Locations, Asia

A technology partner is building an offline-first point-of-sale system for a government program that involves tens of thousands of retail locations across the country. The software is built in Flutter and runs on low-cost Android point-of-sale terminals.

Connectivity at these sites is intermittent, often for hours at a time, and a point-of-sale system that depends on a live server connection stops operating during those windows. With PowerSync, transactions complete on the terminal and reconcile when the link returns, so retail locations keep trading and citizens are served. The deployment is self-hosted on managed Kubernetes, with Postgres as both the source database and the bucket storage.

### Field Technicians, Asia-Pacific

A government-owned telecommunications infrastructure operator is building a native iOS application for its field workforce, numbering in the thousands of technicians. The previous application was a PWA. It handled offline conditions poorly, and iOS updates periodically broke the runtime beneath it.

The replacement is written in Swift and SwiftUI, with PowerSync self-hosted inside the operator's own cloud environment to satisfy in-country data residency requirements. Work orders, calendars, messages and notifications sync to the device. Writes are uploaded through the operator's existing API gateway and backend services, which allows the existing authentication and security model to remain unchanged.

For households waiting on a connection or a repair, the effect is fewer repeat visits. The technician arrives with the complete job record regardless of coverage at the site and can close the work on the first appointment.

### Social Housing Maintenance, Europe

The same pattern turns up again in a housing and care provider that maintains tens of thousands of homes on behalf of local and central government. Its repairs and maintenance application runs on thousands of devices and several of its contracts carry data sovereignty terms that require hosting within the country.

Repairs are recorded at the property, including inside buildings with no reception, which keeps tenant repair histories accurate and complete.

## Security Review and Continuity Risk

In a public-sector deal, the information security review usually asks for things like a SOC 2 report, third-party penetration test results, static analysis and dependency scan output, and a vendor willing to work through a long security questionnaire.

A harder question that often comes up is what happens if the vendor discontinues the product. That is a fair question to put to us, and two of the four customers above are here because it happened to them: both were running MongoDB Atlas Device Sync when it was deprecated.

PowerSync inherently provides continuity guarantees. The PowerSync client SDKs are Apache 2.0 licensed. The PowerSync Service is available as Open Edition under the Functional Source License, which converts to Apache 2.0 over time, so a self-hosted deployment does not depend on our continued existence to keep running.

## Resilience on the Device

PowerSync is designed to support devices offline for extended periods — weeks at a time or even longer.

It is also built to assume unreliable client-side storage. PowerSync maintains checksums per bucket of data on both the client and the server, and validates them as part of every checkpoint. A mismatch should never happen during normal operation, but local storage on inexpensive Android hardware does fail, and processes get killed mid-write. When a bucket checksum does not match, PowerSync re-downloads that bucket automatically.

## Running the Service

A single PowerSync instance supports on the order of 50,000 to 100,000 concurrently connected clients depending on the shape and volume of the synced data, and deployments beyond that use a sharded architecture.

All four example deployments above run PowerSync self-hosted, in each case for residency or sovereignty reasons. It is the same service image with the same sync semantics as PowerSync Cloud, configured through YAML files or admin APIs rather than a dashboard, and it exposes Prometheus metrics and a diagnostics endpoint for monitoring in Grafana or an equivalent. Teams that already run their own infrastructure tend to want their sync layer visible in the same dashboards as everything else.

## What These Deployments Have in Common

A school meals program, a government retail network, a telecoms field workforce and a social housing repairs operation have very little to do with one another, but their requirements are similar nevertheless. Each one needed the application to keep working with no network, the data to stay inside the country, and scalability and reliability to be demonstrated early on.

If you are scoping something with these characteristics, our team is available to work through sizing and architecture before you commit to a design.
