/* Exemplu de System-Versioned Table în MariaDB 11 */
CREATE TABLE utilizatori (
id INT AUTO_INCREMENT PRIMARY KEY,
nume VARCHAR(100),
email VARCHAR(100)
) WITH SYSTEM VERSIONING;
/* Modificăm datele normal */
UPDATE utilizatori SET email = 'nou@email.com' WHERE id = 1;
/* Interogăm baza de date exact cum arăta la un anumit moment în timp */
SELECT * FROM utilizatori
FOR SYSTEM_TIME AS OF TIMESTAMP '2026-03-31 10:00:00';Să fim sinceri: în 2026, dacă pornești o aplicație nouă, instinctul colectiv te împinge direct spre un docker run postgres. Postgres a câștigat războiul simpatiei publice. Totuși, am avut recent un caz la un proiect nou unde am mers pe MariaDB 11 și decizia ne-a scutit de destule bătăi de cap și costuri de infrastructură.
Hai să vedem când chiar are sens să ignori hype-ul și să rămâi pe ramura MySQL, fără să regreți mai târziu.
Optimizer-ul din MariaDB 11 nu mai este vechiul MySQL
Mulți developeri au rămas cu impresia că MariaDB e doar un MySQL cu altă emblemă. Așa era acum mulți ani. Începând cu versiunile 11.x, echipa din spate a rescris complet modelul de cost al optimizerului de interogări.
Înainte, optimizerul făcea niște presupuneri destul de rigide despre indexi și adesea alegea prost planul de rulare dacă aveai join-uri complexe. Acum, estimează mult mai precis costul citirii de pe disc versus citirea din buffer pool. Am testat asta pe o bază de date de monitorizare cu 12 milioane de rânduri într-o singură tabelă. Niște interogări de raportare care înainte agățau procesorul s-au executat cu 30% mai rapid după upgrade, fără să schimbăm vreo linie de cod sau vreun index.
Când aleg MariaDB în loc de Postgres?
Am identificat trei scenarii clare în care MariaDB oferă un avantaj real:
-
Resurse de hosting limitate. Postgres este un consumator serios de memorie din cauza arhitecturii sale bazate pe procese individuale pentru fiecare conexiune. Dacă pornești un startup pe un VPS ieftin de 2GB RAM, Postgres te va lăsa baltă rapid când crește traficul (OOM killer-ul devine cel mai bun prieten al tău). MariaDB folosește thread-uri și vine cu un modul de Thread Pool excelent. Rămâne stabilă și rapidă chiar și cu sute de conexiuni active pe hardware modest.
-
Replicare simplă și stabilă. Dacă ai nevoie de o arhitectură master-slave sau multi-master simplă, MariaDB se configurează incredibil de ușor. În Postgres, gestionarea sloturilor de replicare și dimensiunea directoarelor WAL încă îmi dă stări de anxietate când lucrurile o iau razna în producție.
-
Audit nativ prin System-Versioned Tables. Aceasta este o funcționalitate pe care o ador. Vrei să știi cum arătau datele unui utilizator acum o lună? În loc să scrii triggere complicate și tabele de istoric ca în Postgres, în MariaDB adaugi doar o clauză la crearea tabelei.
Trade-off-ul sincer: Unde pierzi cu MariaDB?
Ar fi greșit să spun doar lucrurile bune. MariaDB are limitele ei evidente în comparație cu Postgres:
- Manipularea JSON-ului. Dacă aplicația ta se bazează masiv pe documente JSON dinamice, Postgres este rege datorită tipului de date
JSONBși a indexării de tipGIN. În MariaDB, JSON-ul este doar un alias pentru text (cu constrângeri de validare). E în regulă pentru salvat setări simple, dar e groaznic dacă vrei să faci căutări complexe în interiorul obiectelor JSON. - Ecosistemul de extensii. În 2026, dacă vrei căutare vectorială pentru AI (pgvector) sau integrări ciudate direct în baza de date, ecosistemul Postgres este mult mai matur și dinamic.
Pentru un SaaS clasic, centrat pe tabele relaționale bine definite și unde bugetul de infrastructură contează, MariaDB 11 este o opțiune excelentă și extrem de stabilă. Voi ce folosiți ca opțiune default pentru proiectele din acest an?