Supabase Realtime Integration: Subscribing to PostgreSQL Changes
When building a real-time chat or task board, polling is inefficient — it loads the database and degrades UX. Supabase Realtime solves this with WebSocket based on PostgreSQL Logical Replication, listening to WAL logs. Change delivery latency is typically under 10 ms, and infrastructure costs drop by up to 50% compared to running your own server. If you need a fast real-time solution, have us integrate Supabase Realtime for you.
How PostgreSQL Logical Replication Works
Logical replication publishes row-level changes. Unlike streaming replication, it lets you subscribe only to specific tables and filter data on the database side. Supabase Realtime uses this mechanism, not table polling. This guarantees each change is received exactly once with minimal latency (usually <10 ms). More details are available in the PostgreSQL documentation.
How to Avoid Race Conditions on State Updates
When multiple clients write to the same table simultaneously, the database ensures transaction atomicity, but the client code may receive events out of order. Use optimistic updates and compare row versions. In the React hook below, we handle INSERT, UPDATE, and DELETE by relying on the unique row id. If events arrive in the wrong order, you can apply RSC (React Server Components) for full synchronization.
Setup and Subscription to a Table
npm install @supabase/supabase-js
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
// Subscribe to all changes in the messages table
const channel = supabase
.channel('public:messages')
.on(
'postgres_changes',
{
event: '*', // INSERT, UPDATE, DELETE or *
schema: 'public',
table: 'messages',
filter: `room_id=eq.${roomId}` // filter by value
},
(payload) => {
if (payload.eventType === 'INSERT') {
setMessages(prev => [...prev, payload.new]);
}
if (payload.eventType === 'UPDATE') {
setMessages(prev =>
prev.map(m => m.id === payload.new.id ? payload.new : m)
);
}
if (payload.eventType === 'DELETE') {
setMessages(prev => prev.filter(m => m.id !== payload.old.id));
}
}
)
.subscribe((status) => {
console.log('Subscription status:', status);
});
// Unsubscribe
return () => { supabase.removeChannel(channel); };
The filter room_id=eq.${roomId} becomes a WHERE room_id = 'value' clause on the PostgreSQL side. This is more efficient than filtering client‑side and reduces data transfer by up to 80%.
React Hook for Subscription
function useRealtimeTable<T>(
table: string,
filter?: { column: string; value: string }
) {
const [data, setData] = useState<T[]>([]);
const supabase = useSupabaseClient();
useEffect(() => {
// Initial load
let query = supabase.from(table).select('*');
if (filter) query = query.eq(filter.column, filter.value);
query.then(({ data }) => setData(data ?? []));
// Subscribe to changes
const channel = supabase.channel(`${table}:${filter?.value ?? 'all'}`)
.on('postgres_changes', {
event: '*',
schema: 'public',
table,
filter: filter ? `${filter.column}=eq.${filter.value}` : undefined
}, (payload) => {
setData(prev => {
if (payload.eventType === 'INSERT') return [...prev, payload.new as T];
if (payload.eventType === 'UPDATE')
return prev.map(item => (item as any).id === (payload.new as any).id
? payload.new as T : item);
if (payload.eventType === 'DELETE')
return prev.filter(item => (item as any).id !== (payload.old as any).id);
return prev;
});
})
.subscribe();
return () => { supabase.removeChannel(channel); };
}, [table, filter?.column, filter?.value]);
return data;
}
// Usage
const messages = useRealtimeTable<Message>('messages', {
column: 'room_id',
value: roomId
});
The hook can be extended with pagination, sort support, or optimistic updates. It reduces code from 50 to 10 lines.
Broadcast — Custom Events
Broadcast does not require database changes:
// Send event to all channel subscribers
await supabase.channel('cursor-positions').send({
type: 'broadcast',
event: 'cursor-moved',
payload: { x: mouseX, y: mouseY, userId: user.id }
});
// Receive
supabase.channel('cursor-positions')
.on('broadcast', { event: 'cursor-moved' }, ({ payload }) => {
updateCursorPosition(payload.userId, payload.x, payload.y);
})
.subscribe();
Broadcast is convenient for cursors, typing indicators, notifications — anything not directly tied to table data.
Row Level Security
Supabase Realtime respects PostgreSQL RLS — a client sees only rows it has SELECT access to.
-- Example RLS: user sees only their own messages
ALTER TABLE messages ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users see own messages"
ON messages FOR SELECT
USING (auth.uid() = user_id);
This is critical for multi‑user applications: even if someone intercepts the WebSocket, they won’t get others’ data.
Why Supabase Realtime Wins Over Polling and Manual WebSockets?
| Method | Latency | DB Load | Implementation Complexity | RLS Support |
|---|---|---|---|---|
| Polling (setInterval) | 1 s to ∞ | high (constant SELECT) | low | yes |
| Manual WebSocket | <10 ms | medium (triggers or NOTIFY) | high | requires custom logic |
| Supabase Realtime | <10 ms | low (logical replication) | very low (3 lines of code) | built-in |
Supabase Realtime wins on all counts: it’s fast, doesn’t burden the database, and integrates RLS out of the box.
| Parameter | SUPABASE REALTIME | Manual WebSocket |
|---|---|---|
| Average latency | <10 ms | <10 ms |
| Implementation effort | 1–2 days | 5–10 days |
| RLS support | built-in | requires implementation |
| Scaling to 10k connections | out of the box | requires tuning |
How We Implement Supabase Realtime
When you order a turnkey Supabase Realtime integration, we provide:
- Configuration of logical replication and Realtime channels
- A React hook (or Vue/Preact) with initial load and automatic state updates
- Setup of RLS policies for each table
- Broadcast channels for custom events (cursors, notifications)
- Documentation: architecture overview, subscription schema, sample queries
- Team training: debugging subscriptions, monitoring connection status
- 2 weeks of post‑delivery support
Our process:
- Analysis: identify which tables need real‑time, what events and filters are required, detect race conditions.
- Design: create a channel scheme, prepare SQL migrations for RLS and replication.
- Implementation: write the hook, configure the server side, integrate into existing code.
- Testing: simulate concurrent changes by 10+ users, measure latency, emulate connection drops.
- Deployment: include in CI/CD, set up error monitoring (Sentry).
Timeline and Cost
A basic integration (1–2 tables, a basic hook, RLS) takes 2 to 4 working days. If many tables, complex logic, or broadcast is needed, the timeline extends to a week. The cost is calculated individually. Contact us to estimate your project.
Typical Mistakes
-
Forgetting to set REPLICA IDENTITY FULL — UPDATE and DELETE come with empty old data. Fix:
ALTER TABLE tablename REPLICA IDENTITY FULL; - Not setting up RLS — clients see all rows in the table. Verify SELECT policies for each protected table.
-
Too broad subscription — without a filter, the client receives all changes on the table, causing extra traffic. Always use
filter.
Our experience: 5+ years developing real‑time applications, 20+ Supabase Realtime deployments in production. We guarantee stable operation under loads of up to 10,000 concurrent connections per instance. Order Supabase Realtime integration today and get a working prototype in 2 days.