"Flutter Supabase Offline Sync: Queued Requests Guide"
Flutter Supabase queue offline requests connectivity_plus sync: a Hive-backed write queue that flushes on reconnect, plus conflict resolution.
Last updated: October 3, 2026 Supabase has no built-in offline sync for Flutter — that's the honest starting point (there's an open RFC in supabase-flutter proposing a cache+queue+sync engine, but it isn't shipped). So production offline-first apps roll their own: write locally first, enqueue the operation, and flush the queue to Supabase when the connection returns. This guide builds exactly that Flutter Supabase queue offline requests connectivity_plus sync pattern: a Hive-backed pending-operations queue, a connectivity_plus listener that flushes it on reconnect, and the conflict-resolution strategies you'll need when two devices edit the same row. What you'll learn The local-first architecture: why the queue sits between your UI and Supabase Building a Hive-backed pending-operations queue (no codegen needed) Listening with connectivity_plus and flushing on reconnect Conflict resolution: last-write-wins, server-wins, and field-level merge Catching up on Realtime events missed while offline When to DIY vs reaching for PowerSync or Brick Common mistakes that corrupt the queue The Architecture: Local-First with a Sync Queue The pattern has three layers: Local store (Hive box): the UI reads from here, so the app works with zero connectivity. Pending queue (another Hive box): every write is recorded as an operation — {table, type: insert/update/delete, payload} — in order. Sync engine : on connectivity regain, it replays the queue against Supabase in FIFO order, marking operations done (or dead-lettering failures). Reads are optimistic: the UI updates instantly from the local store, and the queue reconciles with the server in the background. This is the same shape PowerSync and Brick implement — we're just building the minimal honest version…