Databricks racconta, in un post del 22 luglio 2026, come CLA (CliftonLarsonAllen) e il team Forward Deployed Engineering abbiano costruito un orchestratore per workload agentici usando solo Lakebase Postgres, senza broker di messaggi, cache o scheduler esterni. Il caso d’uso è il parsing di documenti per l’auditing, che riduce i tempi di estrazione da ore a minuti.
L’idea di fondo è nota nella community data engineering — “Postgres come coda” — ma qui diventa un’architettura di produzione grazie alle caratteristiche operative di Lakebase.
La coda su due tabelle
Il cuore è una coppia di tabelle: tasks (una riga per unità di lavoro, con stato, lease e risultato) e task_attempts (una riga per tentativo, con run ID del job, trace ID di MLflow e metadati di costo). Quattro pattern nativi di Postgres le trasformano in una coda robusta:
- Dequeue concorrente e priority-aware con
FOR UPDATE SKIP LOCKEDeORDER BY priority DESC, created_at: ogni worker blocca la riga che prende, gli altri la saltano. - Crash recovery via lease: al dequeue si registra un lease con scadenza; uno sweeper periodico ri-accoda i task il cui lease è scaduto, recuperando il lavoro dei worker terminati.
- Throttling rate-limit-aware: un cap di concorrenza (MAX_CONCURRENT_TASKS), un budget di token (MAX_TPM) o la combinazione dei due, valutati al dequeue nella stessa transazione.
- Callback idempotenti: l’handler accetta stati diversi e tratta i task già terminali come no-op, evitando doppie fatturazioni o elaborazioni duplicate.
Osservabilità senza infrastruttura extra
La dashboard operativa si appoggia ai trigger LISTEN/NOTIFY di Postgres, propagati ai client via Server-Sent Events, con un polling di fallback a dieci secondi. Niente Redis, niente WebSocket server, niente message bus. L’attribuzione dei costi filtra system.billing.usage sui run ID lanciati dall’orchestratore, così ogni applicazione vede solo la propria spesa.
A rendere il pattern sostenibile in produzione sono le proprietà di Lakebase: compute in autoscaling separato dallo storage, autenticazione con token OAuth a vita breve, integrazione con Unity Catalog per identità e permessi, branching e snapshot per clonare la tabella dei task in sviluppo. Il risultato, secondo Databricks, è meno integrazione da gestire e nessun broker aggiuntivo da operare. Resta il caveat implicito: è un pattern adatto a task indipendenti e long-running, non a ogni scenario di orchestrazione.
In sintesi
- Due tabelle Lakebase (tasks e task_attempts) più quattro pattern Postgres bastano per una coda concorrente, crash-resilient e rate-limit-aware.
- LISTEN/NOTIFY + SSE danno una dashboard real-time senza Redis né message bus.
- Autoscaling, OAuth, Unity Catalog e branching rendono il “Postgres come coda” utilizzabile in produzione.
Fonte: Simplify AI agent orchestration with Lakebase Postgres — https://www.databricks.com/blog/simplify-ai-agent-orchestration-lakebase-postgres
Hai qualcosa da aggiungere? Unisciti alla discussione.