-- Postgres: Indexare și query rapid în JSONB (foarte eficient)
CREATE INDEX idx_events_meta ON events USING gin (metadata);
SELECT * FROM events WHERE metadata @> '{"status": "active"}';
-- MySQL: Sintaxă echivalentă, dar necesită coloane generate pentru indexare eficientă
SELECT * FROM events WHERE JSON_EXTRACT(metadata, '$.status') = 'active';Am pornit trei SaaS-uri în ultimii cinci ani și de fiecare dată m-am lovit de aceeași întrebare la început de proiect: MySQL sau Postgres? În 2026, ambele baze de date sunt extrem de mature, dar dacă alegi greșit acum, o să plătești înzecit în facturi de cloud sau în ore de refactoring când treci de primii 10.000 de utilizatori.
Când MySQL e alegerea de bun simț
Hai să fim sinceri: MySQL este în continuare regele simplității și al vitezei brute pe operații de tip read. La un proiect de monitorizare unde aveam peste 15.000 de utilizatori activi zilnic, am mers pe MySQL pur și simplu pentru că replicarea read-only se configurează extrem de ușor și consumă considerabil mai puține resurse de memorie.
MySQL gestionează conexiunile mult mai bine nativ. Dacă ai un SaaS clasic de tip CRUD (facturare, gestiune clienți, un CRM simplu), MySQL e mai mult decât suficient și te va costa cu 20-30% mai puțin la hosting pe instanțe similare.
Trade-off-ul? Suportul pentru JSON și tipuri de date complexe este încă destul de rigid. Dacă începi să faci query-uri grele în câmpuri JSON fără să le indexezi prin coloane generate, performanța scade dramatic când tabela sare de câteva milioane de înregistrări.
Când Postgres îți salvează nopțile
Aici intervine Postgres, care a devenit standardul de facto pentru startup-urile moderne. Postgres nu mai este demult acea bază de date "lentă dar sigură". Cu indexarea GIN pe câmpuri JSONB, poți să stochezi documente întregi fără să pierzi din viteza de căutare.
Am avut un caz concret la un SaaS de analytics: trebuia să salvăm payload-uri custom de la webhooks externe. În MySQL, căutarea prin acele payload-uri îngheța baza de date la doar 5 milioane de rânduri. Am migrat totul pe Postgres, am pus un index GIN și timpii de răspuns la căutare au scăzut de la 4 secunde la doar 18 milisecunde. În plus, dacă ai nevoie de căutare full-text simplă sau de date geografice (prin PostGIS), Postgres e la ani lumină distanță.
Problema ascunsă a lui Postgres: Conexiunile
Totuși, Postgres are o mare problemă pe care mulți developeri o ignoră la început: modelul de procese. Fiecare conexiune nouă în Postgres pornește un proces separat pe server, ceea ce mănâncă RAM rapid. La 500 de conexiuni concurente, o instanță de Postgres poate îngenunchea dacă nu folosești un connection pooler extern ca PgBouncer sau Supabase Supavisor.
MySQL, fiind bazat pe thread-uri, duce mii de conexiuni simultane mult mai lejer, fără să aibă nevoie de proxy-uri suplimentare în fața lui.
Concluzia mea
Regula mea de aur în 2026 e destul de simplă. Dacă SaaS-ul tău e un CRUD clasic, unde vrei costuri minime de infrastructură și scalare orizontală rapidă prin read-replicas, mergi pe MySQL. Dacă ai structuri de date flexibile, analytics direct în baza de date, JSON-uri multe sau vrei să folosești baze de date vectoriale (pgvector) pentru integrări AI, Postgres este singura alegere logică.
Voi ce folosiți pentru proiectele noi din portofoliu? Ați simțit limitările astea pe pielea voastră?