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

MariaDB 11 în 2026: Când merită să renunți la PostgreSQL pentru o aplicație nouă

De Dan Ciobanu, 23 iul. 2026 · 11 vizualizări · 3 like-uri

Postat 23 iul. 2026
sql
-- Activare thread pool și optimizare memorie în /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
# Thread pool nativ - gestiune eficientă a conexiunilor pe resurse puține
thread_handling = pool-of-threads
thread_pool_size = 4
thread_pool_max_threads = 64

# Memorie cache optimizată pentru VPS de 1-2GB RAM
key_buffer_size = 64M
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
max_connections = 500

Toți dezvoltatorii sar pe PostgreSQL din reflex când încep un proiect nou. Am făcut și eu asta ani de zile, dar acum trei luni am avut un proiect secundar unde trebuia să țin costurile de infrastructură la minim. Am pus MariaDB 11 pe un VPS de 4$ cu 1GB RAM și am rămas mască de cât de bine duce sarcina.

Hai să fim sinceri: Postgres e fantastic, dar a devenit un monolit pe care mulți îl aruncă în producție fără să aibă nevoie de 80% din ce oferă. MariaDB 11 schimbă puțin ecuația dacă știi exact ce cauți.

Unde strălucește MariaDB 11 în producție

Primul mare plus este consumul de memorie și modul în care gestionează conexiunile. În MariaDB ai thread_pool inclus nativ în versiunea gratuită community. În Postgres, dacă ai 500 de conexiuni simultane fără un proxy extern gen PgBouncer, serverul tău crapă din lipsă de RAM.

La o aplicație de tip SaaS cu 8k utilizatori activi zilnic, pe o bază de date cu peste 12 milioane de rânduri, MariaDB 11 stă liniștit în 450MB RAM. Aceeași schemă pe Postgres 16 ne mânca lejer 1.2GB RAM doar din overhead-ul conexiunilor idluite și din memoria alocată per proces.

Al doilea punct forte este noul Query Optimizer introdus în seria 11. Până la versiunea 10.11, optimizatorul MySQL/MariaDB făcea alegeri bizare la JOIN-uri complexe. În MariaDB 11 au rescris modelul de costuri, iar query-urile analitice de bază rulează sesizabil mai repede fără să adaugi indexuri exotice.

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

Dacă aplicația ta depinde masiv de date nestructurate, MariaDB e încă în urmă. Suportul de JSON din MariaDB este practic o mapare peste un tip de text (LONGTEXT) cu validare la inserare. Nu ai performanța JSONB din Postgres și nici indexare GIN pe chei interne din JSON.

Extensiile sunt un alt punct slab. În Postgres instalezi pgvector și ai bază de date vectorială pentru AI într-un minut. MariaDB 11 a adăugat suport experimental pentru vectori, dar ecosistemul e la un nivel incipient. La fel și pe partea de GIS: dacă faci o aplicație gen Uber sau Delivery, PostGIS mătură pe jos cu funcțiile spatiale din MariaDB.

Când să alegi MariaDB 11 azi?

Alegi MariaDB 11 fără ezitare dacă:

  • Ai o aplicație clasică relatională (CRUD, e-commerce, ERP, CMS).
  • Vrei să rulezi pe un VPS ieftin și nu vrei să configurezi pgbouncer, patroni sau alte unelte de orchestrare complexă.
  • Vrei replicare Master-Slave simplă care se configurează din 4 comenzi CLI și două fișiere de text.

Rămâi pe Postgres dacă ai nevoie de căutare vectorială serioasă, stochezi documente JSON complexe sau ai nevoie de tipuri de date custom și extensii de nișă.

Pentru proiecte medii, MariaDB 11 e o alegere pragmatică care îți salvează bani de infrastructură și ore de mentenanță. Voi mai folosiți MariaDB în proiecte noi sau a devenit Postgres singura opțiune în echipa voastră?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

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