ClickHouse racconta come Trigger.dev abbia spostato la propria observability da Postgres a ClickHouse. È un customer story pubblicato dal vendor del database, quindi il verdetto è scontato; restano interessanti il percorso tecnico e le motivazioni, raccontate dal co-founder e CTO Eric Allam.
Trigger.dev, nata a Londra nel 2022 come progetto open source, è una piattaforma per eseguire task serverless asincroni: orchestrazione, retry, coda ed esecuzione di workflow che oggi alimentano agenti AI e processi long-running. Ogni esecuzione — chiamata run — genera log, trace ed eventi. Con la crescita degli workflow AI, la telemetria è diventata il problema di scala principale.
Perché Postgres non bastava più
L’impostazione iniziale era la classica “usiamo Postgres e vediamo fin dove arriviamo”. Ha funzionato finché il volume non è cresciuto: log, trace ed eventi finivano in un’unica tabella in continua espansione. Partitioning e ottimizzazioni hanno rimandato il problema, ma aggiungere indici diventava impraticabile, le query rallentavano e persino contare le righe era difficile. Il rischio più serio era che carichi analitici pesanti mettessero a rischio la stabilità operativa del sistema che esegue i task dei clienti.
Il team ha valutato di restare nell’ecosistema Postgres — estensioni OLAP, DuckDB, ParadeDB — ma il timore era che l’analytics rimanesse troppo accoppiato al database operativo. Sentendo esperienze di aziende come Baseline, Highlight e Langfuse, già su ClickHouse per workload di observability, hanno scelto quest’ultimo per performance, interfaccia SQL familiare e modello open source adatto sia al self-hosting sia al cloud.
La migrazione e i risultati
Il team ha aspettato una funzionalità specifica, il nuovo tipo di dato JSON nativo di ClickHouse, adatto alla telemetria molto dinamica. La migrazione è avvenuta a livello di singolo run: i log potevano essere scritti su Postgres o su ClickHouse, spostando gradualmente i nuovi workload senza downtime né interventi da parte dei clienti.
I numeri citati sono due, ed è bene notare che sono auto-riferiti dal cliente: query che recuperano decine di migliaia di righe con una latenza P95 attorno ai 200 millisecondi, e una riduzione consistente dell’ingombro di storage rispetto a prima (senza cifra precisa). Con le materialized view il team ha inoltre aggiunto metriche di utilizzo aggregate in circa un’ora, operazione che su Postgres sarebbe stata molto più onerosa.
Il messaggio, al netto della fonte, è coerente con un pattern noto: separare i carichi analitici da quelli operativi conviene quando la telemetria cresce. Non c’è un benchmark comparativo indipendente, ma la logica architetturale regge.
In sintesi
- Caso d’uso classico: separare l’observability analitica dal database operativo (qui Postgres).
- Numeri auto-riferiti dal cliente: P95 ~200 ms e storage ridotto, senza benchmark indipendente.
- Il tipo JSON nativo e le materialized view sono i due elementi tecnici citati come decisivi.
Fonte: How Trigger.dev is using ClickHouse to scale observability for long-running AI workflows
Hai qualcosa da aggiungere? Unisciti alla discussione.