What It Does
PowerSync is a database synchronization layer that implements offline-first, local-first data patterns for applications. It runs a partial-replication sync engine between a server-side database (PostgreSQL, MongoDB, MySQL, or SQL Server) and an embedded SQLite database on the client device. Applications read and write to the local SQLite instance with zero latency; PowerSync handles conflict resolution and background synchronization when network connectivity is available.
The service was purpose-built for scenarios where intermittent connectivity is expected — field service apps, mobile enterprise tools, and now AI clients like Mozilla’s Thunderbolt. Client SDKs are available for React Native, Flutter, Kotlin, Swift, JavaScript/Web, and .NET. The PowerSync Service (the sync engine) is source-available under the Functional Source License (FSL) and can be self-hosted; client SDKs are Apache-2.0.
Key Features
- Partial replication: sync only the rows each user needs, defined by sync rules (YAML)
- Backend support: PostgreSQL (GA), MongoDB (GA, March 2025), MySQL (beta), SQL Server (alpha, December 2025)
- Client SDK support: React Native, Flutter, Kotlin (Android), Swift (iOS), JavaScript/Web, .NET
- Optimistic updates with automatic conflict resolution via CRDT-inspired semantics
- TanStack integration:
@tanstack/powersync-db-collectionfor React Native and web SDKs - SOC 2 Type II and HIPAA compliant (January 2026)
- Self-hosted via PowerSync Open Edition (FSL source-available)
- PowerSync Cloud managed service with a free tier and pay-as-you-grow pricing
Use Cases
- Mobile enterprise applications that must work reliably in low-connectivity environments
- Multi-device AI clients (like Thunderbolt) needing real-time conversation state synchronization across desktop and mobile
- Field service, logistics, or point-of-sale apps where offline writes must be durably queued
- Applications replacing Firebase Realtime Database/Firestore with a PostgreSQL-backed alternative
- Teams adopting local-first architecture patterns who need a production sync engine rather than building their own
Adoption Level Analysis
Small teams (<20 engineers): Good fit via PowerSync Cloud free tier. The managed service eliminates ops overhead. Client SDK integration typically takes 1–2 days for basic setup.
Medium orgs (20–200 engineers): Strong fit. SOC 2/HIPAA compliance removes blockers for regulated industries. The self-hosted option gives cost control at scale.
Enterprise (200+ engineers): Viable for enterprises that have evaluated local-first architectures. The FSL service license is source-available but not OSI-approved open source — legal teams should review the license terms, particularly the 4-year business-source delayed open-source provision.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| Supabase Realtime | PostgreSQL-native, hosted BaaS, less offline-first emphasis | You need full BaaS (auth, storage, edge functions) not just sync |
| Electric SQL | Postgres-native CRDT sync, Apache 2.0, newer | You want full open-source with no FSL risk |
| Firebase Realtime Database | Google-managed, NoSQL, wide SDK support | You’re in the Google ecosystem and Postgres is not required |
| PouchDB + CouchDB | Mature, Apache 2.0, bidirectional sync | You’re already on CouchDB or need FOSS without FSL concerns |
Evidence & Sources
- PowerSync Official Website
- PowerSync GitHub Organization
- Offline-First Apps Made Simple: Supabase + PowerSync
- PowerSync Open-Source Packages
- Supabase Partners — PowerSync Integration
- This is By Far the Best Database Sync Technology — DEV Community
Notes & Caveats
- FSL license on the service: The PowerSync Service (sync engine) is Functional Source License, not OSI open source. FSL converts to Apache-2.0 after 4 years, but today enterprises cannot fork or redistribute the service without restrictions. The client SDKs are Apache-2.0 with no restrictions.
- MySQL/SQL Server maturity: PostgreSQL support is the most mature and battle-tested. MySQL is beta; SQL Server is alpha as of December 2025. Evaluate carefully before using non-Postgres backends in production.
- Sync rules complexity: PowerSync’s partial-replication model requires writing sync rules in YAML to define which rows sync to which users. This is powerful but adds operational complexity that simple full-replication tools don’t have.
- No built-in conflict UI: PowerSync handles conflicts via its resolution semantics, but complex business logic conflicts (e.g., double-booking) still require application-level handling. Do not assume “offline-first” eliminates all conflict scenarios.