SQLite o MariaDB? Come scegliere il database giusto per un progetto web 🗄️

Quando inizi a sviluppare una nuova applicazione, prima o poi devi scegliere dove conservare i dati. Utenti, impostazioni, prodotti, contenuti, sessioni e informazioni operative hanno bisogno di un sistema affidabile per essere salvati e recuperati.

Per molti progetti PHP, la scelta più immediata è un database come MariaDB. Ma negli ultimi anni SQLite è diventato sempre più interessante anche per applicazioni web, strumenti self-hosted e piccoli servizi.

La domanda è quindi legittima: conviene utilizzare SQLite oppure MariaDB?

La risposta dipende soprattutto da come verrà utilizzata l’applicazione. Entrambi sono database relazionali validi, ma adottano architetture differenti e risolvono esigenze diverse.

Vediamo le differenze senza trasformare la scelta del database in una guerra di religione tecnologica. 😄

Che cos’è SQLite?

SQLite è un motore di database relazionale incorporabile direttamente in un’applicazione.

La sua caratteristica più conosciuta è la possibilità di conservare un intero database in un singolo file.

Non richiede necessariamente un server database separato, un servizio di sistema dedicato o una procedura complessa di installazione.

Un’applicazione può aprire il file del database ed eseguire query SQL attraverso la libreria SQLite.

Questo approccio lo rende particolarmente interessante per:

• applicazioni desktop;
• strumenti locali;
• piccoli servizi self-hosted;
• prototipi;
• applicazioni embedded;
• sistemi che devono essere distribuiti con poche dipendenze.

La semplicità di distribuzione è uno dei suoi punti di forza: in molti casi non devi amministrare un server database aggiuntivo.

Che cos’è MariaDB?

MariaDB è un sistema di gestione di database relazionali basato su un’architettura client-server.

Un servizio database gestisce le connessioni, esegue le query, controlla gli accessi e conserva i dati.

Le applicazioni comunicano con il server utilizzando un protocollo dedicato, generalmente attraverso una connessione locale o di rete.

MariaDB è molto diffuso negli ambienti web e rappresenta una scelta naturale per numerosi progetti PHP, CMS e applicazioni gestionali.

È particolarmente adatto quando devi gestire:

• numerosi utenti concorrenti;
• più applicazioni che condividono dati;
• accessi remoti controllati;
• permessi differenziati;
• repliche e strategie di alta disponibilità;
• carichi di lavoro che richiedono un servizio database dedicato.

1. La differenza principale è l’architettura

SQLite e MariaDB non si distinguono semplicemente perché uno è “leggero” e l’altro è “pesante”. La differenza più importante riguarda il modo in cui vengono utilizzati.

Con SQLite, l’applicazione accede direttamente al file del database attraverso la libreria SQLite.

Con MariaDB, l’applicazione comunica con un server database che gestisce le richieste.

Questo cambia il modo in cui devi progettare distribuzione, backup, concorrenza e amministrazione.

SQLite riduce la quantità di infrastruttura necessaria. MariaDB offre invece un servizio centralizzato pensato per gestire connessioni e operazioni provenienti da più client.

2. SQLite è davvero più veloce?

Non esiste una risposta universale.

SQLite può essere estremamente efficiente per operazioni locali, perché evita parte dell’overhead associato alla comunicazione con un server database separato.

Per query semplici e carichi di lavoro appropriati, può offrire prestazioni eccellenti.

Ma questo non significa che sia sempre più veloce di MariaDB.

Le prestazioni dipendono da numerosi fattori:

• struttura delle tabelle;
• indici disponibili;
• complessità delle query;
• numero di letture e scritture concorrenti;
• dimensione del database;
• tipo di storage;
• configurazione del motore;
• modalità di accesso dell’applicazione.

📊 Un benchmark significativo deve rappresentare il carico di lavoro reale. Confrontare due database utilizzando una sola query semplice può produrre risultati poco utili per una scelta architetturale.

3. La concorrenza è uno dei fattori decisivi

SQLite supporta più lettori concorrenti, ma la gestione delle scritture presenta caratteristiche importanti.

In particolare, un database SQLite consente normalmente un solo writer attivo alla volta.

Con la modalità WAL, acronimo di Write-Ahead Logging, lettori e writer possono operare contemporaneamente in molte situazioni, migliorando la concorrenza rispetto ad alcune modalità tradizionali.

Questo non significa però che SQLite diventi equivalente a un database server progettato per gestire numerose transazioni di scrittura concorrenti.

Puoi approfondire nella documentazione ufficiale SQLite sulla modalità WAL.

MariaDB, utilizzando motori transazionali come InnoDB, offre meccanismi di concorrenza e locking adatti a numerosi carichi applicativi multiutente.

Se il progetto deve gestire molte operazioni di scrittura contemporanee, MariaDB può rappresentare una scelta più naturale.

Se invece l’applicazione effettua prevalentemente letture e un numero moderato di scritture, SQLite potrebbe essere più che sufficiente.

4. Installazione e manutenzione

Uno dei vantaggi più evidenti di SQLite è la semplicità operativa.

Per molte applicazioni non devi:

• installare un servizio database separato;
• configurare utenti di database;
• gestire una porta di rete dedicata;
• mantenere un demone sempre attivo.

Questo può essere particolarmente utile su piccoli server, dispositivi embedded e applicazioni che devono funzionare con poche risorse.

MariaDB richiede invece la gestione di un servizio database, con configurazioni, aggiornamenti, backup e controlli operativi.

Non è necessariamente uno svantaggio: quando il progetto cresce, avere un servizio database separato può semplificare la gestione centralizzata, la separazione delle responsabilità e il controllo degli accessi.

5. Backup: copiare il file SQLite è sufficiente?

Una delle convinzioni più diffuse è che il backup di SQLite consista semplicemente nel copiare il file del database.

In alcuni scenari, quando il database non è in uso e il filesystem è in uno stato coerente, questa operazione può essere sufficiente.

Ma copiare il file mentre l’applicazione sta scrivendo può produrre una copia non consistente, soprattutto se non vengono considerati correttamente journal e modalità WAL.

SQLite mette a disposizione strumenti e API dedicate per creare backup consistenti.

Per esempio, attraverso la shell ufficiale puoi utilizzare:

sqlite3 database.sqlite ".backup backup.sqlite"

Il comando utilizza il meccanismo di backup previsto da SQLite.

Per approfondire puoi consultare la documentazione ufficiale sulle API di backup SQLite.

MariaDB utilizza invece strategie differenti, come dump logici e strumenti di backup fisico.

In entrambi i casi, il principio rimane lo stesso: un backup affidabile deve essere coerente, verificabile e ripristinabile.

6. Sicurezza e controllo degli accessi

SQLite non dispone di un sistema integrato di utenti e privilegi equivalente a quello di un database server come MariaDB.

La protezione del database dipende in larga parte dai permessi del filesystem e dalle misure di sicurezza applicate dall’applicazione e dal sistema operativo.

Se un processo dispone dell’accesso al file SQLite, può eseguire le operazioni consentite dalla libreria e dai permessi del file.

MariaDB permette invece di creare utenti, assegnare privilegi e limitare le operazioni consentite sui database e sulle tabelle.

Questo può essere importante quando più applicazioni o servizi devono accedere allo stesso sistema database con autorizzazioni differenti.

🔐 Attenzione: nessuno dei due sistemi protegge automaticamente un’applicazione da SQL injection. In entrambi i casi è necessario utilizzare query parametrizzate e validare correttamente gli input.

7. Utilizzare SQLite con PHP

PHP supporta SQLite attraverso PDO, quando il relativo driver è installato e abilitato.

Un esempio semplice:

<?php

$pdo = new PDO(
    'sqlite:' . __DIR__ . '/../storage/app.sqlite',
    null,
    null,
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
    ]
);

$stmt = $pdo->prepare(
    'SELECT id, name FROM products WHERE id = :id'
);

$stmt->execute(['id' => 42]);

$product = $stmt->fetch(PDO::FETCH_ASSOC);

Il percorso del database è volutamente collocato fuori dalla directory pubblica dell’applicazione.

È una precauzione importante: non dovresti rendere scaricabile via HTTP il file contenente i dati dell’applicazione.

In un ambiente di hosting, verifica sempre i permessi della directory e la configurazione del web server.

8. Utilizzare MariaDB con PHP

Con MariaDB puoi utilizzare PDO attraverso il driver MySQL, compatibile con numerosi ambienti PHP.

<?php

$pdo = new PDO(
    'mysql:host=127.0.0.1;dbname=app;charset=utf8mb4',
    getenv('DB_USER'),
    getenv('DB_PASSWORD'),
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_EMULATE_PREPARES => false
    ]
);

$stmt = $pdo->prepare(
    'SELECT id, name FROM products WHERE id = :id'
);

$stmt->execute(['id' => 42]);

$product = $stmt->fetch(PDO::FETCH_ASSOC);

In questo caso, l’applicazione si collega a un servizio database e utilizza credenziali dedicate.

Per la produzione è opportuno configurare utenti con privilegi minimi, proteggere le credenziali e gestire correttamente gli errori di connessione.

La documentazione ufficiale di PDO è disponibile su PHP.net.

9. SQLite può essere utilizzato in produzione?

Assolutamente sì, purché sia adatto al carico di lavoro e all’architettura dell’applicazione.

SQLite non è semplicemente un database per esercitazioni o prototipi. Viene utilizzato in numerosi prodotti reali, applicazioni desktop, dispositivi e servizi.

La domanda corretta non è quindi “SQLite è abbastanza professionale?”, ma “SQLite soddisfa i requisiti di questo progetto?”.

Per un’applicazione self-hosted con pochi utenti, scritture moderate e un’architettura semplice, SQLite può essere un’ottima scelta.

Per un gestionale multiutente con numerose operazioni concorrenti, integrazioni esterne e necessità di accesso centralizzato, MariaDB potrebbe risultare più appropriato.

La guida ufficiale SQLite su quando utilizzarlo affronta proprio questi scenari.

10. E se il progetto cresce?

Un’applicazione può iniziare con SQLite e successivamente richiedere un database server.

La migrazione è possibile, ma non sempre banale.

SQLite e MariaDB presentano differenze nella sintassi SQL, nei tipi di dato, nelle funzioni disponibili, nella gestione delle migrazioni e in alcuni comportamenti delle query.

Per ridurre le difficoltà future:

• mantieni l’accesso ai dati separato dalla logica applicativa;
• utilizza query parametrizzate;
• evita di distribuire query SQL in ogni parte del codice;
• gestisci le modifiche allo schema attraverso migrazioni versionate;
• documenta eventuali funzionalità specifiche del database scelto;
• prevedi test per le operazioni più importanti.

Non è necessario progettare ogni piccolo sito come se dovesse diventare una piattaforma utilizzata da milioni di persone.

È però utile evitare scelte che rendano inutilmente difficile un cambiamento futuro.

SQLite o MariaDB: quale scegliere nei diversi scenari?

Per orientarsi, possiamo considerare alcuni casi tipici.

Piccola applicazione self-hosted

Se l’applicazione viene utilizzata da poche persone, gira su un singolo server e non presenta un carico elevato di scritture concorrenti, SQLite può ridurre notevolmente la complessità di gestione.

Gestionale aziendale multiutente

Se molti utenti devono modificare dati contemporaneamente, con permessi differenziati e numerose operazioni transazionali, MariaDB può offrire un’architettura più adatta.

Applicazione desktop

SQLite è spesso una scelta molto naturale, perché il database può essere distribuito insieme all’applicazione senza richiedere un servizio separato.

Sito WordPress

WordPress utilizza tradizionalmente MySQL o MariaDB. SQLite può essere utilizzato attraverso soluzioni specifiche, ma non va considerato un sostituto immediato e completamente equivalente in ogni installazione.

Per un sito WordPress standard, soprattutto con plugin e integrazioni complesse, MariaDB rimane generalmente una scelta consolidata.

SaaS con utenti e organizzazioni differenti

Per un SaaS multiutente, la scelta dipende dal modello di isolamento dei dati, dalla concorrenza, dalle esigenze operative e dalla distribuzione dell’applicazione.

MariaDB può essere una soluzione naturale per un database centralizzato. SQLite può comunque avere ruoli interessanti in architetture specifiche, per esempio con database separati per istanza o tenant, ma richiede una progettazione consapevole.

Tabella riepilogativa

Conclusione: scegli il database in base al progetto, non alla moda 🚀

SQLite e MariaDB sono entrambi strumenti maturi e affidabili, ma nascono per esigenze differenti.

SQLite punta sulla semplicità, sulla portabilità e sulla possibilità di utilizzare un database senza amministrare un servizio separato.

MariaDB offre un’architettura client-server, gestione degli utenti e strumenti adatti a numerose applicazioni web con accessi concorrenti.

Non esiste un vincitore assoluto. La scelta migliore dipende da quanti utenti utilizzeranno il sistema, quante operazioni verranno eseguite, come verrà distribuita l’applicazione e quali requisiti di manutenzione dovranno essere soddisfatti.

La tecnologia giusta non è necessariamente quella con più funzionalità. È quella che risolve il problema reale introducendo il minor numero possibile di complicazioni. 💡