SQLite come database di WordPress: stato di sviluppo, limiti e casi d'uso

Comprendere correttamente WordPress e SQLite

Attualmente WordPress non supporta SQLite come piattaforma di database selezionabile di serie nel core. I requisiti di sistema ufficiali continuano a indicare MySQL o MariaDB; SQLite non rientra tra i requisiti standard per l’installazione di WordPress. Chi utilizza WordPress con SQLite, quindi, non si limita a modificare semplicemente un’impostazione del core, ma integra WordPress con un proprio livello di integrazione.

Questo livello è fornito dal plugin Integrazione del database SQLite Pronto. È disponibile nella directory dei plugin di WordPress.org e viene sviluppato come plugin della community o plugin con funzionalità specifiche. Il suo obiettivo è testare un’implementazione SQLite e raccogliere feedback in vista di una possibile integrazione futura nel core. La sua presenza nell’ecosistema di WordPress.org non implica quindi che sia stato approvato come parte integrante di una normale installazione di WordPress.

L'iniziativa ha una lunga storia alle spalle: nel settembre 2022, all'interno del team WordPress Core, è stato proposto pubblicamente di supportare ufficialmente SQLite a lungo termine. Da gennaio 2023 l’implementazione è disponibile come plugin autonomo; il collegamento a Performance Lab presente all’epoca descriveva una fase di sviluppo, non il percorso standard attuale per ogni sito WordPress.

Per una classificazione attendibile, ciò che conta è il numero di versione. Al momento della ricerca, il 18 ottobre 2026, la versione v3.1.0 dell’8 ottobre 2026 è la versione stabile. Le informazioni provenienti dal ramo di sviluppo non devono essere considerate automaticamente come caratteristiche di questa versione stabile. Viceversa, sarebbe errato equiparare il plugin attivo a un'approvazione generale per l'uso in produzione in ogni contesto di utilizzo di WordPress solo per questo motivo.

Alla domanda del lettore si può quindi rispondere affermativamente solo in misura limitata: SQLite può essere utile per installazioni ben definite, ad esempio per lo sviluppo, le demo o piccoli siti web su un singolo server con modifiche gestibili. Per le installazioni distribuite, con un'elevata attività di scrittura o critiche per l'azienda, MySQL o MariaDB rimangono la base ufficialmente supportata e solitamente più adatta. Fattori determinanti sono l'architettura, i modelli di scrittura e l'effettiva compatibilità dello stack utilizzato.

Database di file, compatibilità "drop-in" e compatibilità SQL

La differenza fondamentale risiede nel modello di memoria. SQLite è un Database dei file: I dati sono memorizzati localmente in un file di database sul file system. MySQL e MariaDB, invece, funzionano come servizi di database autonomi, con cui WordPress comunica tramite una connessione al server. SQLite può quindi consentire un ambiente più snello, ma richiede una posizione di archiviazione locale adeguata e i diritti di accesso appropriati.

Il core di WordPress, i temi e la maggior parte dei plugin utilizzano la nota interfaccia per l'accesso al database wpdb. Il plugin sostituisce il consueto livello di database tramite il drop-in wp-content/db.php. Questo drop-in intercetta le query e funge da ponte tra l'ambiente WordPress, orientato a MySQL, e SQLite. In questo modo, l'interfaccia dell'applicazione rimane la stessa per molti componenti, nonostante cambi la struttura di base del database.

Il livello di mediazione è il punto cruciale alla base dell’affermazione sintetica „WordPress funziona su SQLite“. WordPress non genera automaticamente codice SQL specifico per SQLite. La documentazione del progetto nel ramo di sviluppo trunk descrive un parser MySQL che riproduce la grammatica SQL e le funzioni necessarie per SQLite. Ciò illustra l'approccio di sviluppo, ma non costituisce né una promessa di versione stabile né una garanzia che ogni singola query o estensione MySQL sia compatibile senza necessità di adattamenti.

Dovresti controllare con particolare attenzione le estensioni che generano direttamente codice SQL, richiedono funzioni del database o gestiscono le tabelle interne in modo insolito. Ciò vale anche per gli strumenti di importazione, di reportistica e gli script di manutenzione. Un tema o un plugin può funzionare correttamente in condizioni normali, ma può comunque fallire durante una rara operazione di amministrazione, un aggiornamento o una query specifica a causa di una peculiarità di MySQL non documentata.

Le differenze relative allo schema, ai metadati e alle query tipiche rimangono rilevanti ai fini della valutazione. La panoramica interna su Le tabelle del database di WordPress e le loro prestazioni aiuta a identificare le estensioni che fanno un uso intensivo del database e le tabelle personalizzate come potenziali punti di controllo. Integrazione con SQLite non sostituisce né l'analisi di tali query né la responsabilità di testare, prima dell'utilizzo, eventuali modifiche apportate al di fuori dell'interfaccia standard di WordPress.

Quando l'uso di SQLite è tecnicamente giustificabile

Una decisione sensata non deriva da un numero generico di visitatori. Ciò che conta è la Concorso di scrittura: SQLite consente più lettori in parallelo, ma per ogni file di database può avvenire una sola operazione di scrittura alla volta. Se le modifiche si sovrappongono nel tempo, le operazioni di scrittura successive devono attendere. La documentazione di SQLite consiglia l’utilizzo di un database client-server in caso di numerosi client indipendenti, più computer o molte operazioni di scrittura simultanee.

I campi di applicazione chiaramente definibili sono lo sviluppo locale, i corsi di formazione, le demo e le istanze di test di breve durata. In questi casi non è necessario configurare un servizio MySQL o MariaDB separato, mentre è possibile verificare in modo controllato lo stack di plugin e temi. Anche un piccolo sito web su un singolo server può essere adatto, purché sia prevalentemente di consultazione e le modifiche redazionali siano rare e non si verifichino in modo concentrato nel tempo.

Tuttavia, un sito aziendale essenziale, un blog personale o una pagina dedicata a una campagna non sono automaticamente adatti. Moduli di contatto, aree riservate agli utenti, integrazioni con newsletter o endpoint programmati su misura possono generare ulteriori operazioni di scrittura. Verifica quindi non solo le visualizzazioni delle pagine, ma anche gli aggiornamenti delle opzioni, i dati inseriti nei moduli, le attività pianificate e le modifiche ai dati apportate da plugin e interfacce esterne.

Per i negozi online con ordini, i sistemi di prenotazione e biglietteria, le comunità attive o le applicazioni con numerose operazioni di scrittura AJAX e REST, questa limitazione è solitamente più rilevante. In questi casi, più utenti possono salvare ordini, modificare le disponibilità o creare contenuti quasi contemporaneamente. Anche la presenza di più server web dietro un bilanciatore di carico non è compatibile con l’approccio basato su file locali che SQLite presuppone per questo caso d’uso.

Il caching svolge una funzione diversa rispetto a SQLite. Il caching di pagine o oggetti può ridurre gli accessi in lettura ricorrenti e, di conseguenza, le query al database; tuttavia, non trasforma un’applicazione con un’elevata attività di scrittura in un’installazione SQLite a basso rischio di conflitti. Viceversa, SQLite non sostituisce un sistema di cache. Per i siti web esistenti, mantenere MySQL o MariaDB insieme a un'adeguata cache può quindi rappresentare la soluzione meno rischiosa, senza dover cambiare la piattaforma del database.

Valutare sistematicamente gli scenari con SQLite

A determinare se SQLite sia adatto a WordPress non è il numero di visitatori, bensì l’interazione tra operazioni di scrittura, configurazione del server ed estensioni. SQLite è in grado di gestire accessi in lettura in parallelo, ma non può eseguire operazioni di scrittura sullo stesso file di database in parallelo a piacimento. Pertanto, un singolo sito web con un elevato numero di pagine visualizzate non è automaticamente inadatto, mentre ordini o prenotazioni attivati contemporaneamente possono rappresentare un problema critico.

La tabella rappresenta una preselezione, non un'approvazione definitiva. Soprattutto nel caso di un sito web aziendale di piccole dimensioni, un modulo CRM, un'area riservata ai membri o un servizio di automazione esterno possono trasformare una pagina con pochi aggiornamenti in un caso di carico di scrittura elevato. Al contrario, un blog con molti lettori rimane un candidato plausibile se i commenti, i moduli e le modifiche amministrative sono gestibili. Lo stesso plugin sottolinea che l’idoneità dipende dal traffico e dal carico di scrittura.

Il multisito è descritto nella documentazione di progetto del ramo di sviluppo come uno scenario configurabile; inoltre, il repository contiene test specifici al riguardo. Ciò non implica tuttavia un’approvazione generale per l’uso in produzione in reti di grandi dimensioni con numerosi redattori, siti o integrazioni. Considera quindi una rete come un caso di compatibilità a sé stante e verifica i flussi amministrativi, di aggiornamento e di contenuto effettivamente utilizzati.

Il passaggio pratico obbligatorio consiste nel testare lo stack specifico in un ambiente separato. Ciò include il tema attivo, tutti i plugin in produzione, i plugin MU personalizzati, gli strumenti di importazione, i moduli, gli endpoint REST, nonché gli strumenti di backup e monitoraggio. Non è determinante solo il fatto che le pagine vengano caricate: ogni estensione con proprie istruzioni SQL o modifiche frequenti deve passare in modo affidabile attraverso il livello SQLite.

Installazione e configurazione sicura del percorso

Questa configurazione è adatta per una nuova installazione di prova o per un’installazione di SQLite pianificata con cura, non come soluzione rapida per un ambiente di produzione esistente. Prima dell’attivazione, PHP deve riconoscere l’estensione pdo_sqlite fornire il supporto PDO; inoltre, il plugin richiede SQLite a partire dalla versione 3.37.0. PHP necessita dei diritti di scrittura per la directory del database selezionata. La finestra di dialogo di configurazione verifica questi requisiti e rileva anche eventuali drop-in di database esistenti che potrebbero causare conflitti.

La versione minima di SQLite indicata è un requisito tecnico del plugin, ma non costituisce una garanzia generale per ogni caso d'uso in produzione. A partire dalla versione 3.0 del plugin, Write-Ahead Logging Attivato per impostazione predefinita. Gli amministratori dovrebbero quindi verificare quale libreria SQLite venga effettivamente caricata dal runtime PHP in uso e includere gli aggiornamenti dei plugin, di PHP e di SQLite nelle loro procedure di manutenzione e verifica della compatibilità.

Verifica in particolare wp-content/db.php. Questo file è il drop-in centrale di WordPress per il livello del database; non è possibile utilizzarlo contemporaneamente con altre soluzioni. Se in quella posizione è già presente un drop-in, ad esempio per un altro collegamento al database o per una soluzione di caching, prima dell’installazione è necessario chiarire quale componente fornisca e se sia possibile una rimozione completa.

La versione stabile 3.1.0 utilizza per impostazione predefinita sottodirectory con nomi casuali all'interno di wp-content/database/. Il percorso di salvataggio individuato viene visualizzato in db-path.php registrato e tramite DB_PATH messi a disposizione. Gli strumenti di backup e migrazione non devono quindi presupporre nomi di file storici o un percorso predefinito casuale. Le costanti precedenti DB_DIR e DB_FILE sono contrassegnati come obsoleti nella sezione 3.1; DB_PATH ha la precedenza.

Per una nuova installazione pianificata, il progetto raccomanda di utilizzare un percorso assoluto al di fuori della directory web accessibile pubblicamente. La directory di destinazione deve essere scrivibile dal processo PHP. La seguente impostazione va inserita in wp-config.php Si tratta di un esempio di configurazione, non di una guida per la conversione a posteriori di un sito web già attivo.

// Dateikonfiguration wp-config.php:
// Beispielpfad außerhalb des öffentlich erreichbaren Webverzeichnisses.
define( 'DB_PATH', '/private/wordpress/database.sqlite' );

Avviso: un nuovo DB_PATH Non sposta alcun file di database esistente. Seleziona invece un’altra posizione di archiviazione. Se il valore viene modificato senza adeguata preparazione, WordPress potrebbe quindi utilizzare un database diverso o vuoto. Pianifica insieme il percorso, i diritti di accesso, il backup e un test di ripristino prima dell’implementazione in produzione.

La struttura casuale delle directory nella versione 3.1 riduce semplicemente la prevedibilità del percorso predefinito. Non sostituisce né i diritti del file system né una posizione di archiviazione protetta in modo affidabile contro la divulgazione pubblica. La soluzione più sicura è il percorso consigliato al di fuori della radice del sito web; se si sceglie un'altra posizione di archiviazione, è necessario impedire in modo altrettanto affidabile l'accesso da parte del server web.

Nessun cambio di database tramite attivazione

Nel caso di un sito WordPress esistente che utilizza MySQL o MariaDB, l’attivazione dell’integrazione con il database SQLite non comporta alcuna migrazione. Il plugin crea un database SQLite separato, inizialmente vuoto. I post, gli utenti, le opzioni, i file multimediali e i dati dei plugin presenti nel database precedente non vengono trasferiti automaticamente. Se l’integrazione viene disattivata in un secondo momento, WordPress si ricollega al database precedente; le modifiche apportate in SQLite non vengono riportate nel database precedente.

Questa separazione è utile per i test, ma è fondamentale per le migrazioni in produzione. Chi intende effettivamente trasferire i contenuti su un'altra piattaforma di database necessita di un piano di migrazione proprio e ben definito, che includa il trasferimento dei dati, la verifica dei set di caratteri e delle opzioni, nonché un piano di ripiego. La semplice attivazione del drop-in non può sostituire questo processo.

La denominazione basi di dati separate Va inteso alla lettera: durante il funzionamento di SQLite, i due database possono contenere dati diversi. Un post di prova creato in SQLite non compare improvvisamente in MySQL o MariaDB dopo la disattivazione. Allo stesso modo, un nuovo post creato in MySQL rimane invisibile finché WordPress utilizza il file SQLite come fonte di dati attiva.

Il repository wp-sqlite-db Si definisce un progetto autonomo con un unico drop-in SQLite e rimanda all'integrazione originale di SQLite. Non va quindi confuso con l’attuale repository di WordPress. I file, i valori di configurazione e le istruzioni relativi a questo progetto non devono essere trasferiti all’attuale integrazione del database SQLite; fa fede, in ogni caso, la documentazione del progetto concretamente utilizzato.

Per i siti web esistenti, spesso la scelta meno rischiosa è quella di mantenere MySQL o MariaDB e analizzare separatamente i colli di bottiglia. Il caching a livello di pagina o di oggetto può ridurre le query al database, ma non sostituisce la migrazione dei dati né risolve i problemi di compatibilità legati all’integrazione di SQLite. Per classificare le tipiche query di WordPress e gli approcci di caching, è utile questa panoramica su Prestazioni di WordPress e ottimizzazione della cache.

Proteggere il database SQLite ed eseguirne il backup in modo coerente

Con SQLite, il database di WordPress è contenuto in un unico file sul server. Può includere, tra le altre cose, contenuti, account utente, opzioni e dati di configurazione e deve quindi essere protetto come un server di database. Una sottodirectory predefinita con nome casuale, che utilizza la versione 3.1, rende semplicemente più difficile indovinare il percorso; non sostituisce però i diritti di file correttamente impostati né le restrizioni di accesso del server web.

Il progetto raccomanda di, DB_PATH da specificare come percorso assoluto al di fuori della radice del sito web. PHP necessita di diritti di scrittura in quella posizione, mentre il server web non deve fornire direttamente il file del database. Questa separazione riduce il rischio che un’errata configurazione all’interno della directory accessibile al pubblico renda il file accessibile. L’implementazione, la gestione dei diritti e il backup devono tenere espressamente conto della posizione di archiviazione scelta.

Per i backup, a partire dalla versione 3.1, è fondamentale non specificare in modo fisso né un nome file storico né un percorso predefinito. Il plugin può rilevare il percorso effettivo tramite DB_PATH renderlo disponibile durante l'esecuzione; gli strumenti di backup, migrazione e ripristino devono quindi individuarlo dopo il caricamento di WordPress. Prima di procedere alla messa in produzione, è consigliabile eseguire il ripristino in un ambiente separato e documentare il percorso necessario, la configurazione e le fasi operative.

A partire dalla versione 3.0 del plugin, l’integrazione utilizza di default la modalità WAL. In questo caso, oltre al database principale, possono essere creati file di supporto con le estensioni -wal e -shm possono verificarsi. Verifica quindi espressamente se lo strumento di backup utilizzato supporti il funzionamento in modalità WAL del database SQLite in esecuzione e tenga conto di questi elementi. Senza tale autorizzazione da parte dello strumento, la semplice copia del file principale non consente di ottenere un backup coerente.

La versione minima di SQLite indicata dal plugin, ovvero la 3.37.0, rappresenta il limite tecnico minimo per l’integrazione. Ai fini del funzionamento, dovresti inoltre verificare quale versione di SQLite venga effettivamente utilizzata da PHP e includere nel regolare processo di aggiornamento le correzioni di sicurezza e di bug dei pacchetti PHP e SQLite in uso. Tuttavia, in assenza di una fonte adeguata nell’archivio delle fonti esistente, non è possibile ricavarne una raccomandazione attendibile per singole versioni successive di SQLite o per determinati backport.

Gli strumenti di esportazione e backup non dovrebbero essere utilizzati solo perché sono noti nelle installazioni di MySQL o MariaDB. Verifica, per lo strumento specifico, se supporta il database SQLite nella versione attuale DB_PATH e supportato nella modalità di journal configurata. Esegui quindi un ripristino nell'ambiente di hosting previsto e verifica se il percorso del database, i componenti necessari del database e la configurazione di WordPress vengono integrati correttamente.

Individuare i conflitti e analizzarli in modo mirato

La migrazione va inizialmente effettuata in un ambiente di staging o di test, non nel primo rollout in produzione. Prima dell'installazione, registra i file esistenti in wp-content/db.php nonché plugin, plugin MU ed estensioni personalizzate che utilizzano direttamente MySQL. Un secondo database "drop-in" non può funzionare in parallelo; il processo di configurazione dell'integrazione verifica quindi la presenza di tali conflitti.

Verifica quindi le procedure concrete anziché limitarti alla pagina iniziale: registrazione e amministrazione, creazione di contenuti, ricerca, moduli, attività pianificate, importazione ed esportazione, nonché backup e ripristino. Ripeti i test dopo gli aggiornamenti dei plugin e di WordPress. Il livello di integrazione elabora la sintassi MySQL per SQLite, ma il supporto descritto nel progetto non sostituisce la verifica delle proprie query o delle funzioni meno comuni di un’estensione.

Errori comuni nell'arredamento sono la mancanza di pdo_sqlite rispettivamente pdo oppure diritti di scrittura insufficienti per la directory del database. Altrettanto problematica è l’ipotesi che l’attivazione riprenda i contenuti di un’installazione esistente di MySQL o MariaDB: essa crea un database SQLite separato, non esegue automaticamente una migrazione dei dati. Anche un nuovo DB_PATH non sposta alcun file esistente, ma punta semplicemente a un’altra posizione.

Se si verificano tempi di attesa sotto carico, verifica innanzitutto quali operazioni effettuano scritture simultanee: ad esempio ordini, elaborazione di moduli, richieste REST o attività in background. SQLite consente più lettori, ma serializza le operazioni di scrittura per ogni file di database; inoltre, la presenza di più server web aumenta i requisiti dell’architettura del database. Ciò non è paragonabile ai meccanismi di blocco di MySQL-InnoDB. Per l’analisi delle cause nei database WordPress tradizionali, è utile l’articolo su Accessi simultanei al database e blocchi.

Scegliere la strategia di database più adatta

SQLite è una soluzione accettabile per WordPress se il sito web gira su un singolo sistema, è prevalentemente in lettura e le modifiche simultanee sono limitate e note. È più adatto allo sviluppo locale, alle demo o a piccoli siti web editoriali piuttosto che ad applicazioni con un elevato volume di transazioni. Rimane comunque fondamentale verificare la compatibilità del tema effettivamente utilizzato, dei plugin, degli strumenti di importazione e di tutti gli accessi al database personalizzati.

In caso di implementazioni distribuite, più server web o operazioni di scrittura concentrate in un breve lasso di tempo, rimangono MySQL o MariaDB la strategia di database più adeguata. Ciò riguarda in particolare i negozi online con ordini, i sistemi di prenotazione e biglietteria, le funzionalità di community e le interfacce automatizzate con numerose richieste di scrittura. Il fattore determinante non è il numero complessivo di visitatori, bensì la necessità che processi indipendenti modifichino contemporaneamente lo stesso database. Per l’accesso diretto e simultaneo al database da parte di più host tramite una rete, SQLite raccomanda in linea di principio un sistema client-server.

Per un sito web già esistente, il passaggio a una nuova piattaforma non comporta automaticamente un progetto volto al miglioramento delle prestazioni. Il caching a livello di oggetto o di pagina può ridurre le query al database e il carico di lavoro di PHP senza sostituire MySQL o MariaDB. La cache e SQLite risolvono quindi compiti diversi: la prima riduce le operazioni di elaborazione ricorrenti, mentre la seconda modifica il modello di archiviazione e di funzionamento del database. I requisiti ufficiali di WordPress continuano a indicare MariaDB o MySQL come prerequisiti standard per il database.

Prima dell'approvazione, una verifica "Go/No-Go" dovrebbe coprire almeno i seguenti punti:

• Architettura: WordPress funziona in modo permanente su un singolo server senza che più host debbano aprire lo stesso file SQLite direttamente tramite un file system di rete?
• Modelli di scrittura: gli ordini, le registrazioni, i moduli e le operazioni di scrittura REST o AJAX eseguiti in parallelo sono limitati e verificati in un ambiente separato?
• Compatibilità: il tema, i plugin, i plugin MU e le query SQL personalizzate funzionano nell'istanza di prova?
• Drop-in: il file wp-content/db.php è privo di conflitti con soluzioni relative al database o alla cache?
• Migrazione: È chiaramente documentato che l'attivazione non trasferisce alcun contenuto da MySQL o MariaDB?
• Durata: la libreria SQLite caricata da PHP soddisfa i requisiti minimi di versione del plugin? Gli aggiornamenti di PHP, SQLite e del plugin sono integrati nel processo di manutenzione?
• Backup: il backup rileva il DB_PATH corrente, supporta la modalità di journaling utilizzata ed è stato eseguito e documentato un ripristino in un ambiente separato?
• Operatività: gli aggiornamenti del plugin e di WordPress sono garantiti da una procedura di test ripetibile?