MariaDB è un sistema di gestione di database relazionali open source (RDBMS) nato da MySQL e sviluppatosi nel tempo come progetto indipendente. Utilizza SQL, organizza i dati principalmente in tabelle e viene impiegato in siti web, applicazioni, servizi online e infrastrutture aziendali.
Se gestisci un sito WordPress, potresti già utilizzarlo senza averlo scelto direttamente: molti hosting adottano questo database server al posto di MySQL.
La somiglianza tra i due sistemi, però, può creare un equivoco. Non si tratta semplicemente di “MySQL con un altro nome” e le versioni moderne non devono essere considerate intercambiabili senza verifiche.
In questa guida vediamo come funziona, quali versioni sono realmente stabili, cosa cambia rispetto a MySQL e cosa controllare quando viene utilizzato con WordPress.
Cos’è MariaDB e perché non è più soltanto un fork di MySQL
MariaDB Server è un RDBMS open source che permette di archiviare, organizzare, interrogare e modificare dati strutturati attraverso SQL.
In termini pratici, è il software che riceve richieste come:
SELECT nome, email FROM clienti WHERE attivo = 1;
interpreta la query, individua i dati richiesti e restituisce il risultato all’applicazione.
È quindi utile distinguere subito due concetti.
Un database è l’insieme organizzato dei dati. Un DBMS è invece il software che permette di creare, leggere e gestire uno o più database. Se vuoi approfondire questa distinzione, nella nostra guida completa ai database trovi una spiegazione di database, tabelle, record, chiavi e sistemi di gestione.
Come nasce dal progetto MySQL
Il progetto nasce come fork di MySQL per iniziativa di Michael “Monty” Widenius e di altri sviluppatori legati al database originale.
L’obiettivo iniziale era mantenere disponibile un’alternativa aperta e fortemente compatibile con MySQL. Questa origine comune spiega perché i due sistemi condividano ancora molti concetti, strumenti, convenzioni e modalità di connessione.
Nel frattempo, però, i progetti hanno seguito roadmap differenti.
Parlare ancora di un semplice “clone di MySQL” descrive quindi l’origine, ma non rappresenta correttamente lo stato attuale del software.
Progetto open source ed ecosistema commerciale
Un’altra distinzione importante riguarda la MariaDB Foundation e l’azienda commerciale che sviluppa e distribuisce prodotti della stessa famiglia.
La MariaDB Foundation è un’organizzazione indipendente senza scopo di lucro che lavora per preservare apertura, adozione e continuità di MariaDB Server. Il server resta software libero e open source distribuito sotto GPLv2.
Accanto al progetto community esiste un ecosistema commerciale con prodotti enterprise, servizi gestiti, supporto e componenti destinati a infrastrutture più articolate.
La distinzione è importante perché il nome MariaDB può indicare sia il database open source sia una famiglia più ampia di prodotti. Versioni e cicli di rilascio non coincidono necessariamente fra Community Server ed Enterprise Server.
Come funziona il database
L’architettura è di tipo client-server.
Un’applicazione, un CMS, una shell SQL o uno strumento di amministrazione si collega al server e invia una richiesta. Il DBMS autentica la connessione, interpreta la query, determina come eseguirla, accede ai dati e restituisce il risultato.
Tra l’applicazione e i dati esiste quindi uno strato software che gestisce molto più del semplice salvataggio.
Il server deve occuparsi, tra le altre cose, di connessioni simultanee, autorizzazioni, indici, transazioni, integrità dei dati, concorrenza, caching, logging e recovery.
Database relazionale, tabelle e linguaggio SQL
Il sistema appartiene alla famiglia dei database relazionali.
Le informazioni vengono normalmente organizzate in tabelle formate da righe e colonne. Le tabelle possono essere collegate mediante chiavi, permettendo di rappresentare relazioni fra entità differenti.
Immagina un ecommerce con tre tabelle:
clientiordiniprodotti
La tabella degli ordini può contenere un riferimento al cliente che ha effettuato l’acquisto. Il DBMS può quindi combinare le informazioni attraverso query SQL senza duplicare tutti i dati del cliente dentro ogni ordine.
SQL serve proprio a definire strutture e interrogare i dati.
Puoi, per esempio, creare un database:
CREATE DATABASE negozio CHARACTER SET utf8mb4;
selezionarlo:
USE negozio;
creare una tabella:
CREATE TABLE clienti (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
nome VARCHAR(100) NOT NULL,
email VARCHAR(190) NOT NULL UNIQUE
);
e recuperare successivamente i dati:
SELECT id, nome, email FROM clienti ORDER BY nome;
SQL e il database server non sono quindi sinonimi: SQL è il linguaggio, il DBMS è il sistema che lo interpreta e lo utilizza per gestire i dati.
InnoDB, transazioni e integrità dei dati
Per capire il funzionamento del server bisogna conoscere anche gli storage engine.
Uno storage engine è il componente responsabile di come i dati di una tabella vengono memorizzati, indicizzati e gestiti.
La documentazione ufficiale su InnoDB lo identifica come storage engine predefinito. Supporta transazioni, foreign key, locking a livello di riga e meccanismi di crash recovery.
Una transazione permette di raggruppare più operazioni in una singola unità logica.
Supponiamo che un ecommerce debba:
- creare un ordine;
- registrare il pagamento;
- diminuire la disponibilità di un prodotto.
Se l’ultima operazione fallisce, non vuoi ritrovarti con metà procedura completata e metà no.
Le transazioni aiutano a gestire proprio questi scenari mantenendo coerenti i dati.
È uno dei motivi per cui InnoDB è particolarmente adatto a CMS, ecommerce, gestionali e applicazioni con molte operazioni concorrenti.
Storage engine e architettura estendibile
Il server non è limitato a InnoDB.
La sua architettura supporta diversi storage engine destinati a workload differenti. La documentazione sugli storage engine comprende, tra gli altri, InnoDB, Aria, MyISAM, Memory e componenti specializzati.
Questo non significa che convenga scegliere un motore diverso per ogni tabella.
Per la maggior parte delle normali applicazioni transazionali InnoDB rimane la scelta di riferimento. La stessa documentazione ufficiale lo indica come la scelta migliore nella maggior parte dei casi.
Gli altri engine diventano interessanti quando esiste un’esigenza tecnica precisa che ne giustifica l’utilizzo.
La possibilità di scegliere più motori è quindi una caratteristica architetturale, non un invito a complicare una configurazione che funziona.
Versioni: LTS, rolling release e ciclo di supporto
Il numero di versione conta molto più di quanto possa sembrare.
Una vecchia guida può parlare genericamente di “versione 10”, ma all’interno delle diverse serie possono esserci release ancora supportate, versioni a fine vita e linee che seguono cicli differenti.
La pagina ufficiale di tutte le release di MariaDB Server permette di controllare direttamente lo stato delle versioni disponibili.
Il quadro attuale più importante è questo:
| Serie | Stato |
|---|---|
| MariaDB 12.3 | LTS stabile |
| MariaDB 11.8 | LTS stabile e supportata |
| MariaDB 11.4 | LTS stabile e supportata |
| MariaDB 10.11 | LTS stabile e supportata |
| MariaDB 10.6 | Fine del supporto Community |
| MariaDB 13.0.1 | Release Candidate |
| MariaDB 13.1 | Preview |
La conseguenza pratica è semplice: un numero di versione più alto non identifica automaticamente la release da installare in produzione.
Le release LTS supportate
La serie 12.3 è attualmente una linea LTS stabile.
Una release LTS è pensata per avere una finestra di manutenzione più lunga rispetto alle release rolling. In un ambiente di produzione questo può essere più importante della possibilità di utilizzare immediatamente ogni nuova funzionalità.
Restano supportate anche altre serie LTS, tra cui 11.8, 11.4 e 10.11.
La scelta deve tenere conto dell’intero stack: sistema operativo, hosting, applicazione, driver, plugin, strumenti di gestione e procedure di backup.
La versione più nuova non è automaticamente quella più adatta al tuo progetto.
Release Candidate e Preview non equivalgono a una versione stabile
La numerazione può essere fuorviante.
La serie 13.0 comprende attualmente una Release Candidate, mentre 13.1 è ancora classificata come Preview nella pagina ufficiale delle release.
Una preview serve soprattutto a mostrare e testare ciò che sta arrivando.
Una Release Candidate è molto più vicina alla versione definitiva, ma non equivale comunque a una normale release stabile da adottare automaticamente nei workload di produzione.
Se gestisci un server che deve essere affidabile, quindi, non scegliere una versione solo perché ha il numero più alto. Controlla sempre lo stato effettivo della release.
Versioni EOL: perché 10.6 non dovrebbe essere il punto di partenza
La serie 10.6 ha raggiunto la fine del ciclo di manutenzione Community.
Questo non significa che un sito che la utilizza smetta improvvisamente di funzionare.
Significa però che una versione tecnicamente funzionante può essere contemporaneamente una versione non più appropriata per una nuova installazione.
È una distinzione particolarmente importante nell’hosting: “compatibile con l’applicazione” e “ancora mantenuta dal progetto upstream” non significano la stessa cosa.
Se trovi una vecchia release sul tuo server, il primo passo non è aggiornare alla cieca: verifica percorso di upgrade, compatibilità dell’applicazione, backup e possibilità di rollback.
Community, Enterprise e servizi commerciali: cosa cambia davvero
Quando trovi il nome del prodotto in una documentazione commerciale, devi capire di quale componente si sta parlando.
Per un normale sito WordPress su hosting condiviso, gran parte dell’architettura enterprise non è rilevante. Diventa invece interessante in infrastrutture distribuite, applicazioni mission-critical o ambienti che richiedono alta disponibilità, gestione avanzata e supporto commerciale.
Community Server e licenza open source
MariaDB Community Server è l’edizione gratuita e open source del database.
La documentazione ufficiale di Community Server conferma la distribuzione sotto licenza GPLv2.
È questa la variante che incontri più facilmente nelle distribuzioni Linux, nei server web e in molti ambienti hosting.
Open source, però, non significa “senza necessità di manutenzione”.
Devi comunque gestire aggiornamenti, backup, sicurezza, risorse del server e ciclo di vita della release.
Enterprise Server, piattaforma e proxy
La linea Enterprise è orientata ad ambienti aziendali e include prodotti e componenti che rispondono a esigenze diverse rispetto a una normale installazione Community.
Tra questi rientrano strumenti destinati a disponibilità, sicurezza, amministrazione, clustering, analytics e architetture distribuite.
MaxScale, per esempio, opera come database proxy tra applicazioni e server e può essere utilizzato per routing delle query e scenari di alta disponibilità.
Un punto importante riguarda il versionamento: Community Server ed Enterprise Server non devono essere trattati come se avessero necessariamente lo stesso numero di release corrente.
Quando confronti documentazione o requisiti, controlla quindi sempre quale prodotto viene effettivamente citato.
Vector search: cosa aggiunge davvero
Il progetto ha introdotto anche funzionalità dedicate alla ricerca vettoriale.
La documentazione ufficiale di MariaDB Vector descrive il tipo VECTOR, gli indici vettoriali e le funzioni per eseguire ricerche di similarità. La funzionalità è disponibile a partire dalla serie 11.7.
Questo permette, per esempio, di conservare embeddings e realizzare ricerche semantiche direttamente nel database.
È un’evoluzione interessante, ma non trasforma automaticamente il prodotto nella scelta migliore per qualsiasi applicazione AI.
Il vantaggio diventa concreto soprattutto quando un’applicazione già costruita su questo stack necessita anche di ricerca vettoriale e mantenerla nello stesso sistema riduce la complessità architetturale.
Compatibilità con MySQL: cosa resta uguale e cosa è cambiato
I due database condividono origini, concetti e una parte importante dell’ecosistema.
Ma la domanda utile non è più:
“MariaDB è compatibile con MySQL?”
È:
“Questa versione è compatibile con la versione MySQL e con le funzionalità utilizzate dalla mia applicazione?”
Se vuoi prima capire il funzionamento dell’altro sistema, nella guida dedicata abbiamo spiegato cos’è MySQL e come funziona.
Protocollo, client e compatibilità applicativa
La compatibilità con l’ecosistema MySQL rimane elevata.
La documentazione ufficiale sulla compatibilità fra MariaDB e MySQL conferma la compatibilità del protocollo client e di molte API e librerie utilizzate dalle applicazioni.
Per questo numerosi software progettati originariamente per MySQL riescono a collegarsi anche all’altro server senza modifiche sostanziali.
La possibilità di stabilire una connessione, però, rappresenta soltanto uno dei livelli da verificare.
Un’applicazione può collegarsi correttamente e utilizzare la maggior parte delle query, ma dipendere da una funzione, un tipo di dato, una variabile server o un comportamento che differisce fra i due sistemi.
Perché “drop-in replacement” non è più una regola generale
Nelle prime versioni la relazione era molto più semplice.
La documentazione ufficiale chiarisce che fino alla serie 5.5 le versioni potevano funzionare come sostituti diretti delle corrispondenti release MySQL, pur con alcune limitazioni. Dalla serie 10.0 in avanti i progetti hanno continuato a divergere.
Per questo eviterei una frase categorica come:
“Puoi sostituire MySQL senza controllare nulla.”
Una formulazione più corretta è:
la compatibilità resta elevata, ma una migrazione moderna deve essere verificata sulla combinazione concreta di versioni, schema, query, driver e funzionalità utilizzate.
La differenza diventa sempre più importante man mano che un’applicazione sfrutta caratteristiche avanzate del database.
Cosa verificare prima di una migrazione
Prima di passare da MySQL controllerei almeno:
| Area | Perché controllarla |
|---|---|
| Versioni di partenza e arrivo | la compatibilità varia tra release |
| Storage engine | disponibilità e comportamenti possono differire |
| Tipi di dati | esistono differenze implementative |
| JSON | i due sistemi non lo gestiscono nello stesso modo |
| Authentication plugin | può influire sui client |
| Variabili server | nomi, default e comportamento possono divergere |
| Replica | le configurazioni avanzate richiedono verifica |
| Connector e driver | devono supportare la destinazione |
| Query specifiche | estensioni proprietarie possono creare incompatibilità |
| Rollback | la migrazione deve essere reversibile in caso di problemi |
La decisione non dovrebbe quindi basarsi su frasi come “uno è sempre più veloce dell’altro”.
Le prestazioni dipendono da workload, versione, configurazione, schema, indici e query. Senza un benchmark riproducibile sul caso reale, dichiarare un vincitore assoluto sarebbe poco utile.
Il confronto completo merita inoltre un intento autonomo: qui interessa soprattutto capire perché l’origine comune non garantisce equivalenza tecnica in ogni scenario.
WordPress: compatibilità, requisiti e hosting
Il database è particolarmente rilevante nel mondo WordPress perché il CMS deve conservare contenuti, configurazioni e molte informazioni generate da temi e plugin.
Articoli, pagine, utenti, opzioni, commenti, metadati e dati di WooCommerce finiscono infatti nel database.
WordPress non richiede che il server sottostante sia necessariamente MySQL: supporta anche MariaDB.
Quali versioni sono raccomandate per WordPress
La pagina ufficiale dei requisiti di WordPress raccomanda MariaDB 10.11 o superiore, in alternativa a MySQL.
Qui va però fatta una distinzione importante.
Una soglia generale come 10.11+ non significa che qualsiasi release superiore debba essere considerata automaticamente il miglior default possibile.
L’Hosting Team mantiene infatti una matrice più precisa sulla compatibilità delle versioni server. Nelle raccomandazioni per le nuove installazioni WordPress vengono indicate le linee 10.11.x, 11.4.x e 11.8.x, mentre 12.3 compare tra le release disponibili e ancora supportate a livello di sicurezza.
La conseguenza pratica è importante:
non scegliere il database di WordPress guardando soltanto il numero più alto disponibile nel pannello hosting.
Quale versione scegliere per una nuova installazione
Per un nuovo sito preferirei una release LTS supportata e già raccomandata per lo stack effettivamente utilizzato dal provider.
Se il tuo hosting offre una linea LTS mantenuta e già validata sulla propria infrastruttura, quella può essere una scelta più prudente rispetto a una release appena entrata nel ciclo stabile.
Se invece amministri direttamente il server, verifica almeno:
- compatibilità con la versione WordPress;
- supporto upstream della branch scelta;
- compatibilità del sistema operativo e dei repository;
- versione PHP;
- plugin o applicazioni che eseguono query particolari;
- strategia di backup;
- possibilità di rollback.
Il principio è lo stesso che vale per PHP: “funziona” non equivale automaticamente a “è la versione che sceglierei per una nuova produzione”.
wp-config.php, phpMyAdmin e hosting: dove entra il database nella pratica
WordPress conserva le credenziali utilizzate per collegarsi al database nel file wp-config.php.
Nella nostra guida al file wp-config.php trovi nel dettaglio parametri come:
define( 'DB_NAME', 'nome_database' ); define( 'DB_USER', 'utente_database' ); define( 'DB_PASSWORD', 'password' ); define( 'DB_HOST', 'localhost' );
Noterai che WordPress conserva convenzioni nate dall’ecosistema MySQL. Questo non impedisce al database server sottostante di essere MariaDB.
Se devi invece esaminare direttamente tabelle, record o struttura, puoi utilizzare strumenti come phpMyAdmin; nella guida dedicata spieghiamo come gestire il database WordPress con phpMyAdmin.
Quando WordPress non riesce più a raggiungere il server, il risultato può essere il noto errore nello stabilire una connessione al database.
Questi tre livelli non vanno confusi:
WordPress → configurazione della connessione → database server.
Capire dove si trova il problema evita di intervenire sul DBMS quando, in realtà, sono sbagliati semplicemente host, nome utente o password.
Quando scegliere MariaDB
È una scelta particolarmente naturale quando lavori in un ecosistema già compatibile con MySQL, vuoi utilizzare software open source e disponi di un’infrastruttura che supporta correttamente una release mantenuta.
Non esiste però un motivo tecnico per adottarlo automaticamente in qualsiasi progetto.
La decisione deve partire dai requisiti.
WordPress, WooCommerce e applicazioni web
Per WordPress e WooCommerce può essere una soluzione molto sensata.
Il CMS lo supporta, gli hosting lo conoscono bene e l’ecosistema PHP dispone da tempo degli strumenti necessari per collegarsi a database compatibili con MySQL.
In molti casi la scelta non avviene neppure a livello dell’utente finale: è il provider a gestire database server, aggiornamenti, backup e configurazione.
Per un sito WordPress la domanda più utile diventa quindi:
il mio provider utilizza una versione supportata, adatta alla release WordPress e mantenuta correttamente?
È molto più importante di chiedersi se un DBMS sia teoricamente più veloce dell’altro in un benchmark eseguito su un’infrastruttura diversa dalla tua.
Quando sceglierlo per un nuovo progetto
Lo prenderei seriamente in considerazione quando:
- l’applicazione appartiene già all’ecosistema MySQL;
- il team conosce SQL e gli strumenti correlati;
- serve un RDBMS open source maturo;
- InnoDB soddisfa bene il workload;
- l’infrastruttura o il provider lo supporta nativamente;
- è utile conservare elevata compatibilità con strumenti MySQL;
- alcune funzionalità specifiche risolvono un requisito reale;
- si vuole adottare una release LTS con un ciclo di manutenzione prevedibile.
Nessuno di questi vantaggi elimina comunque la necessità di progettare correttamente schema, indici, query e backup.
Un database mal progettato rimane tale anche quando il software scelto è ottimo.
Quando MySQL o PostgreSQL possono avere più senso
MySQL può essere preferibile quando l’applicazione, il vendor o l’ambiente cloud è sviluppato e validato specificamente sulla sua roadmap oppure quando dipendi da caratteristiche proprie delle versioni correnti.
PostgreSQL può avere più senso quando il progetto nasce attorno al suo ecosistema o richiede funzionalità per cui rappresenta una scelta più naturale.
La decisione non dovrebbe essere:
MariaDB vs MySQL vs PostgreSQL → quale è migliore?
ma:
requisiti → workload → compatibilità → competenze → infrastruttura → manutenzione → scelta.
È lo stesso principio che vale quando devi scegliere il database più adatto a un progetto: la tecnologia deve seguire il problema, non il contrario.
Come iniziare senza trasformarsi in DBA
Non serve conoscere ogni componente interno del server per effettuare i primi test.
Sono sufficienti quattro capacità:
- installare una release appropriata;
- collegarsi al server;
- creare database e utenti;
- eseguire query SQL.
La complessità aumenta quando passi dalla sperimentazione alla produzione.
Download e repository: scegliere una release supportata
Il punto di partenza corretto è la pagina ufficiale di download del progetto, verificando sempre stato e ciclo di supporto della release prima di installarla.
Molte distribuzioni Linux rendono inoltre disponibili i pacchetti direttamente attraverso i propri repository.
Prima dell’installazione controlla:
- stato della release;
- durata del supporto;
- compatibilità con il sistema operativo;
- requisiti dell’applicazione;
- eventuale percorso di upgrade da una versione precedente.
Su un server di produzione eviterei di installare una Preview o una Release Candidate soltanto perché è numericamente più recente.
Come controllare la versione in uso
Se hai già accesso SQL, uno dei metodi più semplici è:
SELECT VERSION();
La funzione restituisce la stringa della versione del server che sta effettivamente rispondendo alla connessione.
Puoi ricevere, per esempio, un risultato simile a:
11.4.x-MariaDB
Su hosting gestiti è spesso possibile trovare la stessa informazione anche nel pannello di controllo o attraverso phpMyAdmin.
Creare un database ed eseguire una prima query SQL
Dopo aver effettuato l’accesso puoi creare un database:
CREATE DATABASE esempio CHARACTER SET utf8mb4;
Creiamo poi una tabella:
USE esempio;
CREATE TABLE articoli (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
titolo VARCHAR(200) NOT NULL,
pubblicato DATETIME NULL
);
Inseriamo un record:
INSERT INTO articoli (titolo, pubblicato)
VALUES ('Primo articolo', NOW());
E recuperiamolo:
SELECT id, titolo, pubblicato FROM articoli;
Questo piccolo esempio contiene già i concetti essenziali:
database → tabella → colonne → record → query SQL → risultato.
La gestione professionale aggiunge poi indici, utenti, autorizzazioni, transazioni, replica, logging, monitoraggio, backup e ottimizzazione.
Sicurezza, backup e aggiornamenti: i controlli che contano in produzione
La scelta del DBMS è soltanto l’inizio.
Un database server deve essere mantenuto lungo tutto il proprio ciclo di vita.
In produzione i problemi più costosi raramente derivano dal non conoscere una particolare funzione SQL. Più spesso arrivano da versioni obsolete, backup inutilizzabili, privilegi eccessivi, aggiornamenti non testati o assenza di un piano di rollback.
Utenti e privilegi minimi
Un’applicazione non dovrebbe collegarsi al database utilizzando un account amministrativo se non ne ha bisogno.
Conviene creare utenti dedicati e assegnare soltanto i privilegi necessari.
Per esempio:
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'una-password-lunga-e-unica'; GRANT SELECT, INSERT, UPDATE, DELETE ON esempio.* TO 'appuser'@'localhost';
L’idea è semplice: se l’applicazione non deve creare utenti globali, amministrare tutti i database o modificare la configurazione del server, non dovrebbe avere quei privilegi.
Il principio del least privilege limita l’impatto potenziale di errori applicativi e compromissioni.
Backup verificabili prima di upgrade e migrazioni
Un backup non è realmente una strategia di sicurezza finché non sai se riesci a ripristinarlo.
Prima di un upgrade importante o di una migrazione conviene disporre di:
- backup aggiornato;
- verifica dell’integrità;
- copia separata dal server principale;
- procedura di restore conosciuta;
- finestra di manutenzione adeguata;
- piano di rollback.
Soprattutto nelle migrazioni fra DBMS simili, l’elevata compatibilità può creare un falso senso di sicurezza.
Il fatto che l’applicazione si avvii dopo la migrazione non dimostra che tutte le query, procedure, tipi di dati e processi asincroni stiano funzionando correttamente.
Aggiornare una release senza affidarsi alla sola compatibilità teorica
Prima di cambiare branch controlla release note e indicazioni ufficiali relative al percorso di upgrade.
Poi prova l’aggiornamento su staging o su una copia ripristinabile dei dati.
Dopo l’upgrade verifica almeno:
- avvio del server;
- error log;
- connessioni dell’applicazione;
- query critiche;
- operazioni di scrittura;
- transazioni;
- charset e collation;
- job pianificati;
- replica, se utilizzata;
- tempi di risposta delle query più importanti.
Per WordPress aggiungerei test su backend, login, pubblicazione, ricerca, operazioni dei plugin e checkout WooCommerce quando presente.
Aggiornare il database non significa soltanto riuscire ad avviare il nuovo processo server: significa verificare che l’intera applicazione continui a comportarsi correttamente.
Conclusione
MariaDB è nato da MySQL, ma oggi va considerato un RDBMS autonomo con una propria roadmap, un proprio modello di release e un ecosistema che comprende componenti community ed enterprise.
Per WordPress rappresenta una scelta pienamente sensata, purché venga utilizzata una release supportata e appropriata allo stack. Per nuovi server conviene privilegiare versioni LTS mantenute, invece di scegliere automaticamente il numero più alto disponibile.
La distinzione più importante riguarda però la compatibilità con MySQL: i due sistemi conservano molti punti in comune, ma non sono equivalenti in ogni dettaglio. Se devi migrare un’applicazione reale, verifica versioni, query, driver, configurazione e procedure di rollback invece di affidarti alla vecchia idea del “drop-in replacement” universale.
Se trovi MariaDB nel pannello del tuo hosting WordPress, quindi, non c’è motivo di considerarlo un database anomalo o una versione minore di MySQL. La domanda utile è un’altra: quale release stai utilizzando, è ancora supportata e il tuo stack è stato verificato per funzionare correttamente con quella versione?