惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
I
InfoQ
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - 【当耐特】
小众软件
小众软件
B
Blog RSS Feed
大猫的无限游戏
大猫的无限游戏
博客园 - 三生石上(FineUI控件)
Engineering at Meta
Engineering at Meta
人人都是产品经理
人人都是产品经理
Microsoft Security Blog
Microsoft Security Blog
Last Week in AI
Last Week in AI
H
Help Net Security
爱范儿
爱范儿
云风的 BLOG
云风的 BLOG
博客园 - 司徒正美
Y
Y Combinator Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Microsoft Azure Blog
Microsoft Azure Blog
L
LangChain Blog
WordPress大学
WordPress大学
GbyAI
GbyAI
Google DeepMind News
Google DeepMind News
腾讯CDC

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
PostgreSQL LISTEN/NOTIFY for Real-Time Multi-Tenant Event...
Ugur Aslim · 2026-06-01 · via DEV Community

Ugur Aslim

PostgreSQL LISTEN/NOTIFY for Real-Time Multi-Tenant Events: Ditching Polling and WebSocket Complexity

I've shipped real-time features in CitizenApp using three different approaches: naive polling (embarrassing), Redis pub/sub (overkill), and now PostgreSQL's native LISTEN/NOTIFY. The third option is what I should have started with.

Most teams reach for Redis or RabbitMQ the moment they need real-time updates. It's the conventional wisdom. But here's the truth: if you're already running PostgreSQL, you have a battle-tested pub/sub system sitting right there. It handles multi-tenancy correctly, scales to thousands of concurrent connections, and eliminates an entire infrastructure dependency—which matters when you're deploying to Render or Vercel where every added service is friction.

Why LISTEN/NOTIFY beats the alternatives

Polling is dead. HTTP requests every 2-5 seconds for "new notifications"? That's technical debt masquerading as simplicity. It wastes bandwidth, kills your database with unnecessary queries, and users see stale data.

Redis is powerful but expensive. Not just in dollars—in operational overhead. You need to manage connection pools, handle failover, monitor memory usage, and keep another service running in production. At CitizenApp's scale (thousands of concurrent tenants), we were paying $50/month for Redis on top of Render just to broadcast notifications that PostgreSQL could handle natively.

WebSockets without a broker are a nightmare. If you're running multiple FastAPI workers (and you should be), a WebSocket connection to Worker A doesn't know about events published by Worker B. You need a message broker to fan-out events across processes. Unless you use PostgreSQL LISTEN/NOTIFY, which handles that automatically.

PostgreSQL's pub/sub is:

  • Transactional. Notifications only fire after a transaction commits.
  • Tenant-aware. Use channel names like tenant_123_notifications and broadcast only to the right subscribers.
  • Zero extra infrastructure. It's part of your database bill.
  • Connection-agnostic. Works across multiple workers, containers, and deployments.

The tradeoff? LISTEN/NOTIFY doesn't persist messages. If no one's listening, the event vanishes. But for real-time notifications, analytics updates, and AI job completions (exactly what CitizenApp needs), that's fine—you want the latest state, not a backlog.

The architecture

Here's what I'm building:

  1. FastAPI WebSocket server that maintains connections from React clients.
  2. Database layer that listens for PostgreSQL notifications on tenant-specific channels.
  3. React client that subscribes to real-time updates without polling.
  4. Horizontal scaling across multiple workers without needing Redis.

The FastAPI side

# backend/main.py
import json
import asyncio
from contextlib import asynccontextmanager
from fastapi import FastAPI, WebSocket, Depends
from sqlalchemy import text
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine
import psycopg

# Global store: tenant_id -> set of WebSocket connections
tenant_connections: dict[str, set[WebSocket]] = {}

async def get_db(request):
    async with AsyncSession(engine) as session:
        yield session

# FastAPI lifespan: start listener in background
@asynccontextmanager
async def lifespan(app: FastAPI):
    task = asyncio.create_task(listen_for_notifications())
    yield
    task.cancel()

app = FastAPI(lifespan=lifespan)

async def listen_for_notifications():
    """
    Connect to PostgreSQL directly and listen for NOTIFY events.
    This runs in the background for the entire app lifetime.
    """
    conn = await psycopg.AsyncConnection.connect(DATABASE_URL)

    # Listen on all tenant channels dynamically
    # In production, you'd track which channels are actually subscribed
    async with conn.cursor() as cur:
        # We'll use LISTEN with a pattern-like approach
        await cur.execute("LISTEN notifications")

    try:
        async for notify in conn.notifies():
            payload = json.loads(notify.payload)
            tenant_id = payload.get("tenant_id")

            if tenant_id in tenant_connections:
                # Broadcast to all WebSockets for this tenant
                disconnected = set()
                for websocket in tenant_connections[tenant_id]:
                    try:
                        await websocket.send_json({
                            "type": payload.get("type"),
                            "data": payload.get("data"),
                        })
                    except Exception:
                        disconnected.add(websocket)

                # Clean up dead connections
                tenant_connections[tenant_id] -= disconnected
                if not tenant_connections[tenant_id]:
                    del tenant_connections[tenant_id]
    finally:
        await conn.close()

@app.websocket("/ws/notifications")
async def websocket_notifications(websocket: WebSocket):
    await websocket.accept()

    # Extract tenant from JWT or query params
    tenant_id = websocket.query_params.get("tenant_id")

    if not tenant_id:
        await websocket.close(code=1008, reason="Missing tenant_id")
        return

    # Register this connection
    if tenant_id not in tenant_connections:
        tenant_connections[tenant_id] = set()
    tenant_connections[tenant_id].add(websocket)

    try:
        # Keep connection open, listen for client disconnects
        while True:
            await websocket.receive_text()
    except Exception:
        pass
    finally:
        tenant_connections[tenant_id].discard(websocket)

@app.post("/api/notifications")
async def send_notification(
    tenant_id: str,
    message: str,
    db: AsyncSession = Depends(get_db),
):
    """
    Example endpoint that triggers a notification.
    The NOTIFY happens inside the transaction.
    """
    # Create the notification record
    await db.execute(
        text("""
            INSERT INTO notifications (tenant_id, message, created_at)
            VALUES (:tenant_id, :message, NOW())
        """),
        {"tenant_id": tenant_id, "message": message},
    )

    # Send the PostgreSQL notification
    payload = json.dumps({
        "tenant_id": tenant_id,
        "type": "notification",
        "data": {"message": message},
    })
    await db.execute(
        text("SELECT pg_notify('notifications', :payload)"),
        {"payload": payload},
    )

    await db.commit()

    return {"ok": True}

The React side

// src/hooks/useNotifications.ts
import { useEffect, useRef } from "react";

export function useNotifications(tenantId: string, onMessage: (data: any) => void) {
  const wsRef = useRef<WebSocket | null>(null);

  useEffect(() => {
    const protocol = window.location.protocol === "https:" ? "wss:" : "ws:";
    const wsUrl = `${protocol}//${window.location.host}/ws/notifications?tenant_id=${tenantId}`;

    const ws = new WebSocket(wsUrl);

    ws.onopen = () => {
      console.log("✓ Real-time connection established");
    };

    ws.onmessage = (event) => {
      const message = JSON.parse(event.data);
      onMessage(message);
    };

    ws.onerror = () => {
      console.error("WebSocket error");
    };

    wsRef.current = ws;

    return () => {
      ws.close();
    };
  }, [tenantId, onMessage]);
}

// Usage in a component
export function NotificationCenter({ tenantId }: { tenantId: string }) {
  const [notifications, setNotifications] = useState<any[]>([]);

  useNotifications(tenantId, (message) => {
    setNotifications((prev) => [message, ...prev]);
  });

  return (
    <div className="space-y-2">
      {notifications.map((notif, i) => (
        <div key={i} className="p-3 bg-blue-50 rounded border-l-4 border-blue-400">
          {notif.data.message}
        </div>
      ))}
    </div>
  );
}

Broadcasting AI job completions

This is where LISTEN/NOTIFY shines in CitizenApp. When an AI feature finishes processing, we immediately notify the user without polling:

# backend/celery_task.py (or similar background job)
async def process_ai_feature(tenant_id: str, job_id: str, db: AsyncSession):
    # ... do AI work with Claude ...
    result = await call_claude_api(...)

    # Save result
    await db.execute(
        text("""
            UPDATE ai_jobs 
            SET result = :result, status = 'completed'
            WHERE id = :job_id AND tenant_id = :tenant_id
        """),
        {"result": json.dumps(result), "job_id": job_id, "tenant_id": tenant_id},
    )

    # Notify the tenant in real-time
    payload = json.dumps({
        "tenant_id": tenant_id,
        "type": "ai_job_complete",
        "data": {"job_id": job_id, "result": result},
    })
    await db.execute(
        text("SELECT pg_notify('notifications', :payload)"),
        {"payload": payload},
    )

    await db.commit()

Gotcha: Connection pooling and LISTEN

Here's where I burned myself: PostgreSQL LISTEN connections can't be reused in a connection pool. Once a connection executes LISTEN, it's pinned to that listener—other queries fail.

Solution: Run LISTEN/NOTIFY on a separate database connection, not the one your FastAPI queries use:


python
# Wrong: connection pool conflict
async with engine.begin() as conn:
    await conn.execute(text("LISTEN notifications"))