Il sito community Lobsters ha completato nel weekend la migrazione da MariaDB a SQLite, concludendo un percorso iniziato nel 2018 che puntava prima a PostgreSQL. Ora il sito gira su un singolo VPS con quattro database SQLite: contenuto primario (3.8 GB), cache (1.1 GB), code (218 MB) e Rack::Attack per il rate limiting (555 MB). CPU e memoria in calo, costi dimezzati, e il sito più reattivo secondo chi lo usa.

Ti riguarda perché dimostra un pattern architetturale controcorrente: non serve un RDBMS tradizionale per un sito che serve una community attiva. SQLite con la giusta architettura regge carichi di produzione che molti associano ancora a sistemi più complessi. Per chi costruisce con gli agenti, è un caso concreto di quanto si può fare con un singolo server e SQLite, come raccontavamo il 14 luglio con DOOMQL.

Il pattern si applica: se il tuo sistema ha più scritture concorrenti sullo stesso dato, SQLite probabilmente non basta. Ma se scrivi su database separati per funzione (come Lobsters fa con contenuto, cache, code e rate limiting), la semplicità operativa compensa.

Nel dettaglio

Il contesto

Lobsters aveva pianificato l’uscita da MariaDB dal 2018, inizialmente verso PostgreSQL. Nel 2025 hanno invece deciso di valutare SQLite, e questo weekend la migrazione è andata in produzione.

L’architettura

Il sistema ora gira su un singolo VPS e usa quattro database SQLite separati, ognuno con una responsabilità:

• Contenuto primario (3.8 GB): storie, commenti, voti, utenti
• Cache (1.1 GB): layer di accelerazione
• Code (218 MB): lavori asincroni
• Rack::Attack (555 MB): rate limiting e blocco richieste abusive

La separazione per funzione evita la contesa su scritture concorrenti, il limite più noto di SQLite. Ogni database può crescere e fare vacuum indipendente.

Il lavoro dietro

La migrazione è documentata nella PR #1949 di Thomas Dziedzic: 30 commit, 188 file toccati, +735/-593 righe. Si appoggia su tre PR precedenti (#1705, #1871, #1924) che avevano preparato il terreno. Il codice Rails è stato adattato, i test verificati, il processo di deploy riscritto.

Cosa è cambiato per chi lo usa

I numeri riportati dal team:

• Uso CPU in calo
• Uso memoria in calo
• Latenza percepita migliore
• Costi operativi dimezzati (una volta spento il VPS MariaDB)

Nessun benchmark formale, ma l’effetto è abbastanza evidente da considerare la migrazione permanente.

Quando SQLite non basta

SQLite ha un modello di concorrenza semplice: un solo processo scrive per volta su un database. Se la tua applicazione ha più processi che scrivono sullo stesso dato contemporaneamente, diventa un collo di bottiglia. Lobsters lo evita separando le scritture per database e sfruttando la cache per ridurre la pressione sul contenuto primario.

Se il tuo carico ha scritture frequenti e concorrenti sullo stesso dataset, PostgreSQL o MariaDB restano scelte migliori. Ma se puoi partizionare per funzione come Lobsters, o se le tue scritture sono serializzabili, SQLite regge carichi sorprendenti.

Implicazioni per chi costruisce

Questa migrazione è un caso di studio per chi sta progettando sistemi che usano agenti: un agente che legge e scrive su SQLite locale può evitare la complessità di un database remoto, con latenza e costi operativi inferiori. Se l’architettura separa le responsabilità (un database per le sessioni, uno per i risultati, uno per i log), il modello single-writer di SQLite non è un limite ma una garanzia di consistenza.

Per approfondire l’uso di SQLite in architetture agentiche, vedi lo scaffolding del sito statico multilingua e l’assistente di analisi dati, entrambi costruiti su SQLite.