-- Interogare JSON în PostgreSQL (folosind JSONB și operatorul ->>)
SELECT id, metadata->>'plan' AS subscription_plan
FROM accounts
WHERE metadata->>'status' = 'active'
AND (metadata->'credits')::int > 100;
-- Echivalentul în MySQL 8.0+ (folosind JSON_EXTRACT / ->>)
SELECT id, metadata->>'$.plan' AS subscription_plan
FROM accounts
WHERE metadata->>'$.status' = 'active'
AND CAST(metadata->>'$.credits' AS UNSIGNED) > 100;Văd tot mai des startup-uri care aleg PostgreSQL doar pentru că „așa se face acum”. Ambele baze de date sunt mature, ambele duc lejer un milion de utilizatori dacă știi să pui un index, dar diferențele reale apar când tragi linie la costuri de infrastructură și la complexitatea modelului de date.
PostgreSQL: Când datele tale nu sunt doar tabele clasice
Dacă construiești un produs care depinde mult de câmpuri nestructurate sau funcționalități moderne de căutare, Postgres este aproape imposibil de bătut. Tipul JSONB cu indexare GIN funcționează excepțional dacă ai atribute dinamice configurabile de clienți sau payload-uri de webhook-uri nestandardizate.
În plus, dacă ai măcar un feature mic de căutare semantică sau AI, extensia pgvector te scapă de încă o bază de date separată precum Pinecone sau Qdrant. La un proiect cu 14k useri activi pe zi, am ținut totul (autentificare, date de business și embeddings pentru căutare) într-o singură instanță Postgres de 4 vCPU fără să gâfâie.
Trade-off-ul sincer? Postgres consumă mai multă memorie per conexiune din cauza modelului bazat pe procese (un proces per client). Fără un connection pooler ca PgBouncer sau Supavisor, o să ai probleme de memorie rapid dacă serverul tău web deschide zeci de conexiuni paralele.
MySQL 8.x: Când vrei throughput brut și mentenanță zero
MySQL (și MariaDB sau variante cloud-native ca PlanetScale/Aurora MySQL) rămâne o mașinărie simplă și extrem de eficientă pe operațiuni tranzacționale clasice (OLTP). Modelul său multi-threaded gestionează mai lejer conexiunile inactive, iar motorul InnoDB are un buffer pool extrem de bine optimizat pentru scrieri rapide și citiri după cheie primară.
La un SaaS de facturare unde aveam aproape exclusiv tabele relaționale clasice și peste 30 de milioane de înregistrări, MySQL ne-a costat cu ~25% mai puțin la instanța de RDS față de un Postgres configurat similar, pentru că n-am avut nevoie de memorie suplimentară pentru overhead-ul conexiunilor și nici bătăi de cap cu VACUUM tuning.
Unde pierde MySQL? Suportul pentru JSON a avansat mult, dar operațiunile pe structuri adânci sunt încă mai greoaie, iar ecosistemul de extensii este mult mai limitat.
Cum aleg eu fără să pierd zile întregi în benchmark-uri
Nu există o alegere greșită pentru un MVP, dar regula mea practică este directă:
- Aleg PostgreSQL dacă știu că voi avea mult JSON interogabil, căutare full-text mai avansată, date geografice (PostGIS) sau vectori pentru AI. E un „cuțit elvețian” excelent.
- Aleg MySQL dacă am un model strict relațional (e-commerce clasic, contabilitate, CRM simplu), echipa are deja experiență solidă pe el și vrem să ținem costul infrastructurii la minim fără mentenanță de rutină.
Voi ce puneți ca default pe un proiect nou anul ăsta?