Realtime Collaboration App. Live everything.

The data flow

• →User makes a change. UI applies it optimistically.
• →Change is sent to the server (server action or API route) and committed to Postgres.
• →Postgres replication broadcasts the change via Realtime.
• →Every subscribed client (including the originator) receives the canonical event.
• →Originator’s optimistic state is reconciled against the canonical event. Other clients update their state.
• →On error, the originator reverts the optimistic update and surfaces a toast.

Subscribing to changes

// hooks/useRealtimeRows.ts
import { useEffect, useState } from 'react'
import { supabase } from '@/lib/supabase'

export function useRealtimeRows<T>(
  table: string,
  filter: string,
  initial: T[]
) {
  const [rows, setRows] = useState(initial)

  useEffect(() => {
    const channel = supabase
      .channel(`${table}:${filter}`)
      .on('postgres_changes',
        { event: '*', schema: 'public', table, filter },
        (payload) => {
          setRows((prev) => applyChange(prev, payload))
        })
      .subscribe()
    return () => { channel.unsubscribe() }
  }, [table, filter])

  return rows
}

Presence

Presence is a separate channel that does not touch Postgres. Each connected client tracks itself with a small object — user_id, name, avatar — and the channel emits events when others join or leave.

const channel = supabase.channel(`presence:doc:${docId}`, {
  config: { presence: { key: userId } },
})

channel
  .on('presence', { event: 'sync' }, () => {
    const state = channel.presenceState()
    setOnline(Object.values(state).flat())
  })
  .subscribe(async (status) => {
    if (status === 'SUBSCRIBED') {
      await channel.track({ userId, name, joinedAt: Date.now() })
    }
  })

Optimistic UI without tears

The hardest part of realtime is reconciling optimistic state with the authoritative state coming back over the channel. The trick is to give every optimistic action a temporary local ID, then match the canonical event by either the server-assigned ID or the unique fields the user just edited.

Keep optimistic state in a separate slot from canonical state. Render canonical when present, fall back to optimistic when not. Never mutate canonical state in place to add optimistic-only data; that is how you end up with rows that ghost in and out on reconnect.

CRDTs: only when you must

For most realtime apps, last-write-wins on individual fields is fine. Two users editing the same row at the same instant is rare; when it happens, the second write overwriting the first is a tolerable edge case.

For collaborative free-form text editing — many users in the same paragraph — you need CRDT or operational transform. Y.js works well, but introduces a meaningful complexity tax: a separate document model, sync layer, and persistence path. Only adopt when the user experience genuinely requires it.

Operational considerations

• →Throttle or debounce high-frequency events (cursor moves, typing) before they hit the channel
• →Consider broadcast (no DB write) for ephemeral signals; reserve postgres_changes for actual data
• →Reconnect handling: clients drop and reconnect; on reconnect, re-fetch canonical state, do not trust accumulated state
• →Rate-limit per-channel subscribers if user-driven channel names are possible
• →Monitor channel count and message rate — Supabase has limits, generous but real