DuckDB è un database analitico in-process e single-node, e proprio quel “single-node” spaventa quando lo si affianca alla parola “produzione”. Mehdi Ouazza di MotherDuck propone una mappa del percorso di self-hosting, livello per livello, con un avvertimento esplicito: i benchmark citati servono a illustrare un trade-off, non a fornire numeri su cui decidere. Due forze spingono lungo la mappa: più reader spingono verso l’alto, più writer concorrenti spingono verso destra.
Build versus buy
Sotto ogni scelta c’è la vecchia decisione build-versus-buy. Il costo del self-hosting non è la licenza (DuckDB è gratis), ma la tariffa propria o del team moltiplicata per il tempo di costruzione e manutenzione. L’AI ha reso il building economico, ma la manutenzione è semmai più difficile, perché si rivede meno codice e quando qualcosa si rompe alle 3 di notte si apre una black box. L’abilità più difficile, secondo l’autore, è capire quando smettere di costruire e passare a un servizio gestito.
I livelli
Al Livello 1 tutto gira su laptop: compute accanto allo storage su NVMe locale, con letture puntuali e scansioni su un dataset di esempio da 21 GB (una tabella lineitem da 810 milioni di righe). Al Livello 2 i dati si spostano su object storage come S3 e compare la prima box: l’autorizzazione (ruoli IAM). Quando i dati crescono, anche il compute va nel cloud, aggiungendo una seconda box di auth e un’interfaccia, spesso un’estensione DuckDB scritta in C++.
Al Livello 3 la scelta è tra scale up (una macchina più grande, spesso su Kubernetes con un pod per utente) e scale out (molti piccoli worker con un coordinator, in stile map-reduce). Il Livello 4 riguarda i molti reader: il collo di bottiglia diventa la tail latency sotto carico concorrente, dove una singola box a CPU condivisa peggiora mentre l’isolamento per utente la mantiene piatta; c’è anche la via DuckDB-WASM nel browser, con il limite dell’heap a 32 bit intorno ai 4 GB. Il Livello 5 è il muro dei molti writer: due processi DuckDB non possono scrivere sullo stesso file. Le due strade sono Quack, un protocollo client-server ancora molto giovane che serializza le scritture, e DuckLake con un catalogo Postgres, table format basato su Parquet in cui metadati e transazioni vivono nel database invece che come file su S3.
- Ogni livello aggiunge silenziosamente una box da costruire e mantenere: interfaccia, osservabilità, affidabilità (snapshot, backup, recovery).
- Con DuckLake il pattern di produzione tipico è batch più retry; i dati Parquet restano portabili, ma il catalogo è la parte “sticky”.
- La decisione più difficile non è costruire una singola box, ma riconoscere il momento in cui la manutenzione smette di valere la pena.
Fonte: Self-hosting DuckDB: the road to production — https://motherduck.com/blog/self-hosting-duckdb-road-to-production
Hai qualcosa da aggiungere? Unisciti alla discussione.