Am trecut prin zeci de setup-uri de baze de date în ultimii 10 ani și văd aceeași greșeală repetată obsesiv. Lumea alege baza de date din inerție sau pentru că e la modă pe Twitter. În 2026, diferențele s-au mai uniformizat, dar decizia încă îți poate bloca scalarea sau îți poate dubla costurile de hosting din prima zi.
Hai să dăm la o parte hype-ul și să vorbim pe cifre și cazuri reale.
Regele Postgres și hype-ul conexiunilor
Postgres este, fără îndoială, favoritul comunității de developeri în acest moment. Suportul pentru JSONB este incredibil, iar extensii precum pgvector au devenit standardul de facto dacă vrei să bagi puțin AI în SaaS-ul tău.
Dar am pățit-o anul trecut cu un SaaS mic de monitorizare. Am pornit direct cu Postgres pe AWS. La doar 3.000 de utilizatori activi, costurile cu memoria ne-au lovit direct în buget din cauza conexiunilor. Postgres creează un proces separat în sistemul de operare pentru fiecare conexiune activă. Fiecare proces mănâncă în jur de 10 MB de RAM.
Dacă folosești serverless (cum ar fi Next.js pe Vercel) și funcțiile tale lambda bombardează baza de date cu conexiuni scurte, rămâi fără memorie imediat. Da, poți pune un PgBouncer în față, dar asta înseamnă încă o piesă în infrastructură pe care trebuie să o configurezi, să o monitorizezi și să o plătești.
De ce MySQL încă are sens pentru 80% din proiecte
MySQL (mai ales versiunile recente 8.4 și 9.0) e stabil ca o stâncă și mult mai iertător cu resursele la început de drum. Modelul lui de threading (one thread per connection) consumă mult mai puțină memorie.
Am rulat un magazin online destul de măricel, cu vârfuri de 15.000 de sesiuni concurente, pe o instanță modestă de MySQL de doar 15 dolari pe lună pe un VPS chior. A mers brici, fără niciun connection pooler extern. Dacă ai un model de date pur relațional—tabele clasice de utilizatori, abonamente, facturi și log-uri—MySQL este adesea mai rapid la scrieri simple și mult mai ușor de administrat.
În plus, dacă folosești un serviciu ca PlanetScale (care rulează Vitess peste MySQL), scalarea orizontală devine o problemă rezolvată de alții, fără să îți prinzi urechile în sharding manual.
Trade-off-ul sincer pe care trebuie să-l faci
Nu există o bază de date mai bună la modul absolut. Alegerea se reduce la tipul de date și la modul în care vrei să scalezi:
- Alege Postgres dacă: Ai nevoie de căutare full-text avansată direct în bază, lucrezi cu date geo-spațiale complexe (PostGIS e de neegalat) sau vrei să stochezi embedding-uri vectoriale pentru AI. Postgres excelează când ai interogări analitice complexe.
- Alege MySQL dacă: Vrei costuri minime de hosting la început, ai un model de date strict relațional și vrei o bază de date care pur și simplu funcționează fără să ceară mentenanță zilnică. Este ideală pentru aplicații CRUD clasice.
La un proiect recent am ales MySQL doar pentru că echipa era formată din developeri juniori. Curba de învățare pentru optimizarea interogărilor în Postgres e semnificativ mai abruptă decât în MySQL, unde query optimizer-ul e ceva mai simplist, dar mai predictibil pentru cineva la început de drum.
Voi ce folosiți ca default când porniți un proiect nou acum? Mergeți direct pe Postgres sau mai dați o șansă bătrânului MySQL?