Nothing new to deploy
Supabase’s Data API and Realtime are the sync protocol - no sync service, no replication slot, no second bill.
Nothing new to deploy
Supabase’s Data API and Realtime are the sync protocol - no sync service, no replication slot, no second bill.
Real Postgres on both ends
The client is PGlite, not SQLite: the same SQL, the same types, and migrations you can lift from the server.
Your RLS policies are the sync rules
Downloads and writes go through PostgREST as the signed-in user, so there is no second authorization language to keep in step.
Two-way sync that merges per column
Offline writes queue per transaction and upload only the columns that changed, so two people editing different fields of a row both keep their edit.
Three lines to adopt
A PGlite extension plus one sync() call - no codegen, no schema DSL, no client-side query
language to learn.
Small, permissive, batteries included
Apache-2.0 with zero runtime dependencies, plus a SharedWorker multi-tab host, React and Vue
bindings, and a typed status and event API.
import { PGlite } from '@electric-sql/pglite';import { createClient } from '@supabase/supabase-js';import { supapower } from 'supapower';
const supabase = createClient('https://xyzcompany.supabase.co', 'your-publishable-key');const pg = await PGlite.create({ extensions: { supapower } });
// Two-way sync, from here on: local reads and writes, offline included.await pg.supapower.sync({ supabase, tables: ['todos', 'lists'] });
await pg.sql`INSERT INTO todos (title) VALUES (${'Test Supapower'})`;