La scelta del database è spesso un compromesso tra carichi diversi: analytics e transazioni raramente stanno bene nello stesso sistema. Trainy, azienda Y Combinator, racconta come ha risolto il problema per Pluto, il suo experiment tracker open source, tenendo i dati OLAP su ClickHouse Cloud e migrando il metadata layer relazionale da Amazon RDS a ClickHouse Managed Postgres. Il risultato: costi più bassi, caricamenti pagina fino a 3 volte più veloci e OLAP e OLTP sotto un unico vendor.
Il contesto: Pluto e il problema di Neptune
Trainy nasce per gestire l’allocazione del compute su cluster GPU. Il secondo prodotto, Pluto, è un experiment tracker open source nato dopo che Neptune AI, molto usato dai loro clienti, è stato acquisito da OpenAI a fine 2025 e chiuso. L’open source qui è un punto centrale: come dice il co-fondatore Roanak Baviskar, “impedisce che una situazione come quella di Neptune possa ripetersi”. Per un ML engineer che guarda decine di run con migliaia di metriche, la velocità delle dashboard è tutto.
OLAP su ClickHouse, OLTP su Postgres
Le metriche si comportano come dati di observability (medie, min/max nel tempo) e vivono su ClickHouse Cloud, dove le query dietro le visualizzazioni tornano tipicamente in 50–100 millisecondi al P50, anche su run con centinaia di migliaia di step. L’ingestion è stata affidabile al 100% fin dal primo cliente, senza mai perdere un data point. Tutto ciò che è relazionale — tempo di creazione della run, iperparametri, metadata — restava invece su Postgres.
La migrazione da RDS
Il layer Postgres su Amazon RDS creava due problemi: i default di partenza erano troppo costosi per il volume, e i caricamenti iniziali delle pagine erano lenti perché l’app doveva richiedere i metadata a RDS. Essendo già utenti soddisfatti di ClickHouse Cloud, quando è arrivato il servizio Managed Postgres la scelta è stata naturale, anche per restare nello stesso account. Un vantaggio tecnico rilevante è lo storage: ClickHouse Managed Postgres gira su NVMe locale invece che su storage network-attached, quindi l’accesso al disco è più rapido. Il metadata migrato era di circa 40–50 GB, destinato a crescere.
Confrontando i dati di sessione prima e dopo, i caricamenti iniziali sono 2–3 volte più veloci rispetto a RDS. Un utente ha commentato “è il più veloce di sempre”; una query complessa per identificare quali run erano crashati passava da 10–15 minuti a circa 5 secondi. Considerando che gli utenti aggiornano una dashboard anche 300 volte al giorno, quei millisecondi contano. Per il futuro Trainy punta ad ampliare l’accesso agentic ai dati (via MCP) e a unificare le query tra ClickHouse e Postgres per i financial ops, sfruttando anche ClickPipes per la replica CDC.
- Trainy tiene le metriche OLAP su ClickHouse Cloud (query in 50–100ms al P50) e i metadata relazionali su Managed Postgres.
- La migrazione da RDS ha ridotto i costi e reso i caricamenti pagina 2–3x più veloci, grazie anche allo storage NVMe locale.
- Unificare OLAP e OLTP sotto un vendor apre la strada a query congiunte e accesso agentic ai dati via MCP.
Fonte: Why Trainy migrated from Amazon RDS Postgres to ClickHouse Managed Postgres — https://clickhouse.com/blog/trainy-postgres-managed-by-clickhouse
Hai qualcosa da aggiungere? Unisciti alla discussione.