eduardweb.
MySQL & MariaDBÎncepător#postgresql#database#sql#mariadb

MariaDB 11 în 2026: Mai are sens să o alegi în locul lui Postgres?

De Mihai Popescu, 23 mai 2026 · 5 vizualizări · 3 like-uri

Postat 23 mai 2026
sql
-- Crearea unei tabele cu istoric automat în MariaDB 11
CREATE TABLE preturi_produse (
    produs_id INT NOT NULL,
    pret DECIMAL(10,2) NOT NULL,
    PRIMARY KEY (produs_id)
) WITH SYSTEM VERSIONING;

-- Interogarea stării datelor de la o anumită dată din trecut
SELECT * FROM preturi_produse 
FOR SYSTEM_TIME AS OF '2026-03-01 12:00:00';

Toată lumea dă cu Postgres în sus și-n jos de parcă alte baze de date relaționale au dispărut de pe pământ. Recunosc, și eu sunt în tabăra asta de cele mai multe ori. Dar anul trecut, la un proiect de e-commerce cu vreo 12.000 de utilizatori activi pe zi și un buget strâns pe infrastructură, am fost forțat de circumstanțe să merg pe MariaDB 11. Clientul avea deja infrastructura optimizată pe stack-ul ăsta și n-am vrut să intru în lupte administrative inutile.

Surpriza a fost că nu am mai găsit vechea bază de date rigidă de acum mulți ani. MariaDB 11 vine cu niște chestii care m-au făcut să nu mai regret atât de mult lipsa Postgres-ului.

Optimizer-ul chiar funcționează acum

Dacă ai lucrat cu MySQL sau versiuni mai vechi de MariaDB, știi durerea: interogări complexe care brusc decideau să facă table scan în loc să folosească indexul ăla bun. În versiunea 11, echipa a rescris modelul de costuri pentru optimizer.

Acum deciziile de query plan se bazează pe statistici mult mai precise. Am economisit cam 30% la timpul de execuție pe query-urile de raportare complexe fără să adaug niciun index suplimentar față de structura inițială. Engine-ul InnoDB a fost și el finisat, iar lock-urile pe tabele la scrieri concurente nu mai sunt atât de agresive.

Chestia care m-a cucerit: System-Versioned Tables

În Postgres, dacă vrei să păstrezi istoricul modificărilor pe o masă (audit log), trebuie să scrii triggere, să creezi tabele de istoric sau să instalezi extensii terțe care vin cu overhead-ul lor. În MariaDB 11, ai asta nativ, direct în engine.

Declari tabela ca fiind WITH SYSTEM VERSIONING și baza de date se ocupă de tot. Poți să interoghezi datele exact cum arătai la un anumit moment în timp. Pentru aplicații financiare sau de inventar, chestia asta e aur curat și salvează sute de linii de cod de backend și potențiale bug-uri.

Trade-off-uri sincere: Unde pierde în fața Postgres

Să fim realiști, nu e totul roz. Dacă aplicația ta se bazează masiv pe documente JSON nestructurate și ai nevoie de indexare avansată pe proprietăți imbricate, Postgres cu jsonb și indexare GIN rulează cercuri în jurul MariaDB. MariaDB are suport pentru JSON, dar e practic stocat ca text cu validări de tip, deci performanța la căutări complexe scade rapid pe seturi mari de date.

Un alt minus este ecosistemul de extensii. Postgres are pgvector pentru AI, PostGIS pentru geolocație complexă și o comunitate uriașă care scoate tool-uri pe bandă rulantă. MariaDB are și ea GIS, dar comunitatea e mult mai mică și axată pe use-case-uri tradiționale de web.

Când să alegi MariaDB 11 în 2026?

Mergi pe MariaDB dacă ai deja experiență în echipă cu ecosistemul MySQL, dacă rulezi pe servere VPS mai slabe (consumă sesizabil mai puține resurse la pornire și idle decât Postgres) sau dacă ai nevoie neapărat de audit out-of-the-box prin system versioning.

Dacă ai nevoie de analiză complexă de date, tipuri de date custom sau vectori pentru AI, Postgres rămâne rege.

Voi ce ați mai folosit în ultima vreme pentru proiecte noi? A mai rămas cineva pe MariaDB sau am trecut toți pe Postgres din inerție?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.