CREATE TABLE user_profiles (
id INT AUTO_INCREMENT PRIMARY KEY,
meta JSON,
-- Creăm o coloană generată virtuală pentru a putea pune index
country VARCHAR(50) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(meta, '$.address.country'))) VIRTUAL,
INDEX idx_country (country)
);Toată lumea pe Reddit și Twitter zice să pui Postgres la orice proiect nou în 2026. Am căzut și eu în capcana asta de câteva ori, dar recent, la un proiect de monitorizare cu vreo 12.000 de senzori activi, am mers pe MariaDB 11. Și nu-mi pare rău deloc, ba chiar am economisit vreo 30% la costurile de hosting pentru că rulează brici pe instanțe mici.
Hai să fim sinceri: Postgres e excelent, dar a devenit un fel de alegere implicită „blind”. Lumea uită că MariaDB a evoluat enorm, mai ales de la versiunea 11 încoace, unde echipa din spate a rescris complet modelul de costuri al optimizatorului de interogări.
Unde strălucește MariaDB 11 (și de ce am ales-o)
Primul mare plus e consumul de resurse la pornire. Am ridicat un VPS de 4 dolari pentru un MVP. Postgres cu 1 GB RAM gâfâie destul de repede dacă nu-i faci un tuning agresiv și dacă ai spike-uri de conexiuni. MariaDB folosește un model bazat pe thread-uri care pur și simplu gestionează mai bine conexiunile simultane multe și scurte, specifice aplicațiilor web PHP, Python sau Node.js, fără să ai nevoie de un proxy extern complicat gen PgBouncer.
Al doilea argument: replici master-slave (sau master-master) în 5 minute. În MariaDB, GTID (Global Transaction ID) funcționează atât de simplu încât poți face setup-ul din câteva comenzi de consolă. La Postgres, streaming replication-ul încă îți cere să fii pe jumătate sysadmin ca să nu-ți prinzi urechile în fișierele de configurare.
La proiectul de care ziceam, scriem cam 500 de rânduri pe secundă. Cu motorul InnoDB din MariaDB 11, n-am avut nicio secundă de lag pe replica de citire, iar configurarea a durat literalmente zece minute.
Compromisul dur: unde te bate Postgres de te ascultă
Nu totul e roz. Dacă ai de lucru cu date JSON complexe, MariaDB te face să plângi. În timp ce Postgres are tipul de date JSONB (stocat binar, indexat cu indecși GIN de-ți zboară căutările), MariaDB încă stochează JSON ca text simplu (LONGTEXT). Ca să indexezi ceva dintr-un JSON în MariaDB, trebuie să creezi o coloană persistentă generată, pe care abia apoi pui index. E peste mână și mănâncă spațiu de stocare degeaba.
Iar dacă ai nevoie de GIS (date geografice complexe), PostGIS n-are rival în industrie. Funcțiile geometrice din MariaDB sunt bune doar pentru chestii de bază (gen "găsește restaurante pe o rază de 5 km").
Cum arată un index pe JSON în MariaDB 11
Dacă totuși ai documente JSON și vrei performanță în MariaDB, cam ăsta e workaround-ul pe care l-am folosit ca să nu omorâm baza de date la căutări bazate pe atribute din payload:
Concluzia mea
Pentru mine, regula în 2026 e simplă. Dacă fac un SaaS clasic (utilizatori, abonamente, facturi, ceva analytics simplu) și vreau să-l rulez ieftin și să-l scalez prin replici fără bătăi de cap, MariaDB 11 e o opțiune extrem de solidă. Dacă am nevoie de căutări full-text avansate direct în DB, mult JSON nestructurat sau hărți complexe, strâng din dinți, configurez PgBouncer și merg pe Postgres.
Voi ce ați ales pentru ultimul proiect pornit de la zero și care a fost factorul decisiv?