-- Postgres: Index parțial extrem de util pentru SaaS (doar userii activi)
CREATE INDEX idx_active_subscribers
ON users (subscription_id)
WHERE status = 'active';
-- MySQL (până la versiunile recente nu avea indecși parțiali nativi,
-- trebuia să folosești coloane generate virtuale pentru a obține același efect)
ALTER TABLE users
ADD COLUMN active_sub_id INT GENERATED ALWAYS AS (IF(status = 'active', subscription_id, NULL)) VIRTUAL,
ADD INDEX idx_active_subscribers (active_sub_id);Hai să fim sinceri: în 2026, războiul dintre MySQL și PostgreSQL nu mai e despre care e mai stabilă. Ambele sunt niște tancuri. Dacă ai un SaaS nou de ridicat, alegerea greșită nu-ți va omorî startup-ul, dar îți poate mânca nopțile și bugetul de cloud. Am trecut prin ambele tabere la proiecte de la zero la peste 50k utilizatori activi și am adunat câteva cicatrici.
Uite cum pun eu problema când încep un proiect nou, fără bullshit de marketing.
Mitul "Postgres e mereu alegerea corectă"
În ultima vreme, pare că dacă nu folosești Postgres, ești un fel de dinozaur. E cool să ai Postgres. Dar lumea uită că Postgres e un monstru gurmand. Fiecare conexiune nouă în Postgres pornește un proces separat în sistemul de operare. Dacă ai un SaaS serverless sau folosești containere care scalează rapid și deschid sute de conexiuni scurte, Postgres o să-ți îngenuncheze serverul foarte repede.
La un proiect trecut, un serviciu de monitorizare cu vreo 8.000 de useri activi, aveam spike-uri mari de trafic. Am mutat baza de date de pe Postgres pe MySQL și am economisit cam 30% la costurile de hosting doar pentru că MySQL gestionează conexiunile mult mai eficient prin thread-uri, nu prin procese separate. Da, poți pune PgBouncer în față la Postgres, dar e încă o piesă în mișcare pe care trebuie să o configurezi și să o monitorizezi.
Când Postgres este imbatabil
Postgres câștigă detașat când ai nevoie de flexibilitate și structuri complexe. Dacă SaaS-ul tău are treabă cu AI-ul (și în 2026 cam toate au), extensia pgvector e standardul de aur pentru stocat vectori. Să faci asta în MySQL e pură masochism.
Un alt mare plus sunt indecșii parțiali. Să zicem că ai o tabelă uriașă de users și vrei să pui un index doar pe cei care au abonament activ. În Postgres faci asta extrem de simplu, economisind spațiu pe disc și memorie RAM.
De asemenea, suportul pentru JSON în Postgres (JSONB) este în continuare mult peste ce oferă MySQL ca performanță la interogări complexe și indexare pe chei imbricate.
Trade-off-ul de care nu-ți spune nimeni
MySQL e incredibil de iertător. Îl arungi pe cel mai ieftin VPS de 5 dolari, cu setările default, și va rula fără probleme până când ai un volum serios de date. Postgres, în schimb, are nevoie de tuning aproape din prima zi. Setările default din postgresql.conf sunt extrem de conservatoare, gândite istoric să ruleze pe orice mașină veche. Dacă nu știi să configurezi shared_buffers sau work_mem, te vei întreba de ce se mișcă atât de lent pe un server cu 16GB RAM.
Cum alegi în 2026?
Regula mea simplă de deget este:
- Aleg MySQL dacă fac un SaaS clasic (B2B, CRM simplu, e-commerce, facturare) unde am în principal operații de tip CRUD, vreau costuri minime de mentenanță și infrastructură simplă.
- Aleg Postgres dacă am nevoie de geo-locație avansată (PostGIS), funcționalități de AI/vectori, sau dacă arhitectura mea se bazează masiv pe stocare de documente JSON nestructurate pe care trebuie să fac căutări complexe.
Voi pe ce ați ridicat ultimul proiect? V-ați lovit de limitări de conexiuni pe Postgres sau ați rămas fani MySQL pentru simplitate?