-- Exemplu MariaDB 11: System-Versioned Tables (istoric automat fără triggere)
CREATE TABLE comenzi (
id INT AUTO_INCREMENT PRIMARY KEY,
status VARCHAR(20) NOT NULL,
total DECIMAL(10, 2) NOT NULL
) WITH SYSTEM VERSIONING;
-- Schimbăm statusul
UPDATE comenzi SET status = 'LIVRAT' WHERE id = 101;
-- Interogăm starea exactă din trecut fără tabel separat de audit
SELECT * FROM comenzi
FOR SYSTEM_TIME AS OF '2026-02-01 10:00:00'
WHERE id = 101;M-am lovit recent de o discuție aprinsă în echipă când trebuia să alegem baza de date pentru un microserviciu nou. În 2026, reflexul automat al oricărui dev e să dea docker run postgres și să meargă mai departe. Dar am testat MariaDB 11 pe o aplicație de producție cu 12.000 de scrieri pe minut și am rămas surprins să văd cât de bine se comportă pe hardware limitat.
Reflexul Postgres și unde greșim
Toți iubim Postgres. Este incredibil de stabil, are pgvector, extensii pentru orice și un suport JSONB impecabil. Însă uităm adesea cât de repede mănâncă resursele dacă nu ai un DBA sau timp de tuning avansat.
Postgres folosește câte un proces separat pentru fiecare conexiune. Dacă ai un app server fără un pooler dedicat (cum e PgBouncer), 200 de conexiuni simultane pe un VPS mic cu 4GB RAM o să-ți pună procesorul în cap. MariaDB folosește un model bazat pe thread-uri, iar în versiunile recente 11.x au refăcut din temelii optimizatorul de interogări (Optimizer Cost Model). Asta înseamnă că interogările complexe făcute de juniori sau ORM-uri ieftine nu mai blochează tot serverul la fel de ușor.
Unde câștigă MariaDB 11 în producție
Am avut anul trecut o migrare pentru o platformă de e-commerce cu 85.000 de produse active și trafic masiv în campanii. Bugetul de infrastructură era fix, așa că am analizat ambele variante.
- Sistemul de Replicare și Galera Cluster: Să configurezi un cluster multi-master în MariaDB durează 15 minute. În Postgres, până pui la punct Patroni cu Etcd, îți trece pofta de viață.
- Update-uri masive fără Vacuuming: Postgres suferă masiv când ai tabele de audit sau stări care se schimbă continuu (mutați rândul X, marchează ca procesat). Deși
autovacuums-a îmbunătățit, am pățit des să avem spike-uri de I/O. InnoDB din MariaDB scrie modificările în Undo Log și nu suferă de problema "table bloat-ului" la fel de agresiv. - Sintaxa temporală nativă: MariaDB suportă System-Versioned Tables direct din SQL standard, fără să instalezi extensii sau să scrii triggere obositoare.
Unde Postgres rămâne rege nedronat
Nu vreau să par fanboy orb. Sunt scenarii clare unde MariaDB 11 te va limita rapid:
- Lucrul cu date JSON: În MariaDB, coloana
JSONe doar un alias pentruLONGTEXTcu o validareCHECK. Nu ai indexare B-Tree nativă pe chei interioare ca în JSONB-ul din Postgres. Dacă aplicația ta stochează payload-uri flexibile și faci căutări des în ele, stai pe Postgres. - AI și Embeddings: Dacă ai nevoie de căutări vectoriale pentru LLM-uri,
pgvectore standardul industriei. MariaDB abia acum recuperează terenul. - Geolocație avansată: PostGIS este la ani lumină distanță de ce poate MariaDB pe spațial.
Concluzia mea? Dacă faci un SaaS clasic, e-commerce sau migrezi o aplicație veche unde memoria e scumpă, MariaDB 11 oferă performanță brută excelentă din cutie. Dacă ai date semi-structurate sau AI, mergi pe Postgres. Voi ce folosiți ca default la proiectele noi anul ăsta?