PowerSync
Offline-first sync engine — Postgres/Supabase data replicated to local SQLite.
About
PowerSync is a sync layer for offline-first apps: it replicates a subset of your Postgres (or Supabase) database into a local SQLite database on each client, so reads are instant, writes work with no connection, and everything reconciles automatically when connectivity returns. The architecture is client ↔ PowerSync SDK ↔ PowerSync service ↔ Postgres — the service tails a Postgres publication and streams per-user rows down, while the SDK replays queued local writes back up through your normal API layer (so RLS and triggers keep applying).
SDKs cover the modern client landscape: TypeScript/web (WA-SQLite/OPFS), React Native, Flutter, Kotlin Multiplatform (with a Room integration), and .NET, with first-class Supabase connectors. Sync Streams scope data per user (typically auth.user_id()), conflicts resolve with column-level last-writer-wins, and the service can be self-hosted via Docker or run on PowerSync Cloud.
This is genuinely local-first infrastructure rather than a cache: the local SQLite DB is the source of truth for the UI. The price is operational surface — you run Postgres, the PowerSync service, and the client SDKs together — and sync-rule design (what each user is allowed to download) is the main thing to get right. For field apps, POS systems, and anything used where networks are unreliable, it removes an entire class of hand-rolled sync bugs.
What it can do
- Bidirectional sync between Postgres/Supabase and local SQLite on clients
- Sync Streams with per-user scoping via auth context
- Automatic conflict resolution (column-level last-writer-wins) and offline queuing
- SDKs for web, React Native, Flutter, Kotlin/Room, .NET, with Supabase connectors
- Self-hostable service (Docker) or managed PowerSync Cloud
- Real-time push of changes to connected clients
Setup
- Add your tables to a Postgres publication for PowerSync to tail.
- Deploy the PowerSync service (Docker compose or PowerSync Cloud) and write sync rules.
- Install the client SDK (e.g.
@powersync/web,@powersync/react-native). - Define the client schema and connector; reads/writes go to local SQLite, sync runs in the background.
Prerequisites
PostgreSQL 14+ or Supabase; the PowerSync service (self-hosted Docker or Cloud); a client app using a supported SDK.
Use cases
Works with
Trust score — 8/10
Scored 8/10 (metrics tier, metrics-v1). Evidence: 733 GitHub stars (powersync-ja/powersync-js); Apache-2.0 license confirmed via GitHub API; repo pushed 2026-10-14; Supabase connector, Sync Streams per-user scoping, column-level last-writer-wins conflicts verified against docs and community integration guides; SDKs for web, React Native, Flutter, Kotlin/Room, .NET; service self-hostable via Docker. Manual review: smaller star count reflects niche, not weakness — local-first sync is genuinely hard and the architecture (Postgres publication tailing) is sound; sync-rule design is the main footgun, well documented. License: Apache-2.0.
★ 733 GitHub stars
How the trust score is built
Full methodology →- Adoption · stars/downloads, log-scaled vs peers
- 6.0/10
- Maintenance · recency, releases, issue load
- 8.0/10
- Openness · license + docs
- 10.0/10
- Manual review · sanity read + red-flag check
- 8.0/10
- · 733 GitHub stars (powersync-ja/powersync-js); Apache-2.0 license confirmed via GitHub API; repo pushed 2026-10-14
- · Supabase connector, Sync Streams per-user scoping, column-level last-writer-wins conflicts verified against docs and community integration guides
- · SDKs for web, React Native, Flutter, Kotlin/Room, .NET; service self-hostable via Docker
- · manual review: smaller star count reflects niche, not weakness — local-first sync is genuinely hard and the architecture (Postgres publication tailing) is sound; sync-rule design is the main footgun, well documented
Sources
Every fact above was checked against these sources. Where a claim comes from the provider and couldn't be independently verified, the text says so.