-- În Postgres poți rula migrații de schemă în mod tranzacțional în condiții de siguranță:
BEGIN;
ALTER TABLE subscriptions
ADD COLUMN trial_ends_at TIMESTAMP WITH TIME ZONE DEFAULT NULL,
ADD COLUMN stripe_customer_id VARCHAR(255);
CREATE INDEX idx_subscriptions_stripe ON subscriptions(stripe_customer_id);
-- Dacă linia de mai jos eșuează, tot blocul de mai sus face ROLLBACK automat
UPDATE subscriptions SET trial_ends_at = NOW() WHERE status = 'trialing';
COMMIT;Am lansat anul trecut un micro-SaaS de billing și m-am lovit din nou de vechea dilemă: MySQL sau Postgres? În 2026 ambele baze de date sunt mature și extrem de rapide, dar diferențele de arhitectură îți pot complica viața când aplicația începe să crească. Am strâns mai jos câteva concluzii trase din producție, fără mituri vechi de acum zece ani.
DDL Tranzacțional: motivul principal pentru care înclin spre Postgres
Cea mai mare durere de cap pe care am avut-o în trecut cu MySQL a fost la migrațiile de schemă în producție. Dacă rulați o migrație complexă cu 5 pași și al 4-lea eșuează, MySQL lasă primii 3 pași aplicați. Rămâi cu baza de date într-o stare intermediară și trebuie să faci curățenie manual, cu emoții.
Postgres suportă tranzacții DDL complete. Pui BEGIN;, faci ALTER TABLE, adaugi coloane, modifici tipuri de date, iar dacă ceva crapă, dai ROLLBACK și baza rămâne intactă. Pentru un SaaS unde faci deploy de 3 ori pe zi și rulezi migrații automate în CI/CD, chestia asta îți salvează nopțile.
E drept că MySQL 8.0 și 8.4 au introdus opțiuni ca ALGORITHM=INSTANT pentru multe operațiuni DDL, dar comportamentul nu e uniform pentru toate modificările de schemă.
Extensii și suport JSON: mai mult decât un simplu document store
Dacă aplicația ta are nevoie de stocare de documente semi-structurate sau căutări mai speciale, Postgres e pur și simplu din altă ligă. Suportul pentru jsonb și indecșii GIN permit interogări ultra-rapide în interiorul structurilor JSON.
Mai mult, ecosistemul de extensii din Postgres îți permite să amâni adăugarea altor servicii în infrastructură:
- Ai nevoie de geolocație? Folosești
PostGISîn loc de o bază de date separată. - Vrei căutare semantică sau un feature mic de AI? Folosești
pgvector. La un proiect recent cu 12k utilizatori, am economisit peste $150/lună renunțând la Pinecone în favoareapgvectorintegrat direct în Postgres.
MySQL are și el suport bun pentru JSON în versiunile recente, dar manipularea și indexarea lor rămân mai rigide.
Unde MySQL încă bate Postgres: amprenta de resurse și simplitatea
Să fim sinceri și despre părțile unde MySQL câștigă teren. Dacă pornești un SaaS cu buget de bootstrap și vrei să îl ții pe un VPS ieftin de 5$ cu 1GB RAM, MySQL (sau MariaDB) va rula impecabil. Postgres folosește un model bazat pe procese (fork) pentru fiecare conexiune, pe când MySQL folosește thread-uri. Fără un connection pooler ca pgBouncer, Postgres va mânca memoria RAM extrem de repede când cresc conexiunile paralele.
De asemenea, replicația master-replica și configurarea de read-replicas sunt în continuare ceva mai intuitive în MySQL pentru un developer la început de drum.
Ce alegi în final?
Mergi pe MySQL dacă construiești o aplicație clasică CRUD, vrei un setup simplu care consumă puține resurse pe un server ieftin și nu ai de gând să faci trucuri avansate cu datele.
Alege Postgres dacă construiești un SaaS complex, ai nevoie de migrații sigure în CI/CD, folosești date JSON intensiv sau vrei să integrezi căutări vectoriale fără alte unelte externe.
Voi ce folosiți implicit pe proiectele noi pe care le începeți anul ăsta?