-- În MySQL
SELECT id, name
FROM users
WHERE settings->>'$.notifications.push' = 'true';
-- În PostgreSQL
SELECT id, name
FROM users
WHERE settings->'notifications'->>'push' = 'true';De fiecare dată când încep un SaaS nou, mă blochez jumătate de zi în alegerea bazei de date. În 2026, diferențele s-au micșorat enorm, dar o decizie proastă tot te costă ulterior bani și timp de refactoring. Uite cum văd eu lucrurile după ce am trecut prin ambele tabere la proiecte cu mii de utilizatori activi.
Unde excelează MySQL: Viteza brută și simplitatea
MySQL rămâne regele simplității în deployment. Dacă faci un SaaS clasic de tip CRUD, unde ai în mare parte operațiuni de scriere și citire simple (gândește-te la o aplicație de facturare sau un CRM simplu), MySQL e incredibil de rapid și mănâncă puține resurse.
Am avut un proiect cu peste 12.000 de utilizatori zilnici unde foloseam MySQL pe o instanță ieftină de 10 dolari pe lună. Replicarea de tip master-slave se configurează extrem de ușor și funcționează brici. Cel mai mare avantaj? Modelul de thread-per-connection. E foarte iertător cu conexiunile deschise aiurea din cod. Spre deosebire de Postgres, unde fiecare conexiune e un proces separat în sistemul de operare și îți termină RAM-ul imediat dacă nu ești atent.
PostgreSQL: Când ai nevoie de „heavy lifting”
Postgres nu mai este demult doar o bază de date academică. Dacă SaaS-ul tău implică geolocație (modulul PostGIS este pur și simplu de neatins), analiză de date complexă sau lucrezi mult cu documente JSON nestructurate, Postgres e singura variantă logică.
Suportul pentru JSON în Postgres este atât de rafinat încât de multe ori elimină complet nevoia de a adăuga un MongoDB în stack-ul tău. Poți pune indexuri pe chei din interiorul unui JSON și căutările zboară.
Totuși, trade-off-ul e dureros: Postgres e un monstru când vine vorba de consumul de resurse. Dacă nu îi pui un PgBouncer în față de la început, la primul spike de trafic o să vezi cum serverul crapă din lipsă de memorie. Am pățit asta la un import masiv de date unde scriptul PHP deschidea conexiuni noi în buclă.
Comparație pe JSON: Cum arată interogările
Să luăm un caz real. Vrei să extragi utilizatorii care au activat notificările de tip push dintr-un câmp JSON numit settings.
În MySQL folosești operatorul ->> sau funcția JSON_EXTRACT. Sintaxa a devenit destul de curată în ultimele versiuni. În Postgres, ai operatorul ->> care face același lucru, dar motorul de indexare GIN din spate face ca scanarea pe milioane de rânduri să fie mult mai eficientă.
Cum decizi în 2026?
Dacă pornești singur, vrei să livrezi repede, folosești un VPS mic și vrei mentenanță zero, mergi pe MySQL. Este incredibil de stabil și iartă multe greșeli de începător.
Dacă ai bugete de cloud (unde poți folosi servicii managed gen AWS RDS sau Supabase care se ocupă ei de conexiuni) și știi că vei avea nevoie de căutare full-text avansată, tipuri de date custom sau analiză complexă de date, mergi pe Postgres. Să migrezi ulterior de la MySQL la Postgres e un calvar pe care nu-l doresc niciunui programator.
Voi ce folosiți acum pentru proiectele noi? Mai are sens MySQL în era Supabase și Postgres-first?