Overview
The WebSocket API provides real-time streaming of PostgreSQL database changes to connected clients. When you connect to the WebSocket endpoint, you’ll receive an initial snapshot of all changes and then continuous updates as new changes occur.Connection
Endpoint
Establishing Connection
Message Types
The server sends JSON messages with the following structure:WebSocketMessage Interface
The type of message being sent:
initial: Sent immediately after connection with all existing changeschange: Sent when new database changes occur
Array of database change objects. Each change includes the operation type, table name, and all row data.
Total number of changes tracked by the server. Only included in
change messages.Change Object
The database operation that occurred. Possible values:
INSERT: New row was createdUPDATE: Existing row was modifiedDELETE: Row was removed
The fully qualified table name in the format
schema.table (e.g., public.users).All columns from the affected row are included as additional properties. Column names become property keys with their corresponding values.
Message Examples
Initial Message
Sent immediately when a client connects, containing all previously captured changes:Change Message
Sent in real-time when database operations occur:Batch Changes
Multiple changes from a single operation are sent together:Connection Lifecycle
On Connect
Server sends initial state
If changes exist, server immediately sends an
initial message with all accumulated changesOn Disconnect
- Server removes client from broadcast list
- Connection can be re-established at any time
- Upon reconnection, client receives fresh
initialmessage with all changes
Automatic Reconnection
Implement reconnection logic for robust connections:Broadcasting Behavior
All connected clients receive the same messages simultaneously. Changes are broadcast to every active WebSocket connection.
Server Implementation
The server maintains a set of connected clients and broadcasts messages:Client Message Handling
Clients can send messages to the server, though the current implementation primarily logs them:The WebSocket protocol supports bidirectional communication, but the primary data flow is server-to-client for database change notifications.
Error Handling
Connection Errors
Message Parsing Errors
Close Codes
Normal closure, typically when client intentionally disconnects or component unmounts.
Browser tab closed or navigating away from page.
Connection lost unexpectedly (network issues, server crash).
Best Practices
Implement Reconnection
Always include automatic reconnection logic with exponential backoff to handle network interruptions gracefully.
Parse Messages Safely
Wrap JSON.parse() in try-catch blocks to handle malformed messages without crashing your application.
Track Connection State
Monitor
readyState and connection events to update your UI and inform users of connection status.Clean Up on Unmount
Always close WebSocket connections when components unmount to prevent memory leaks and ghost connections.