Dacă ești la început cu un SaaS în 2026, probabil te gândești că nu contează așa mult ce alegi. „Oricum am un ORM”, zici tu. Ei bine, am zis și eu asta la un proiect cu 8k useri activi și m-am trezit că Prisma sau Drizzle nu mă salvau de lock-urile pe tabele la migrații mari în MySQL. Alegerea bazei de date e una dintre puținele decizii tehnice care te pot costa luni de muncă irosite mai târziu.
MySQL nu mai e doar „fratele mai mic”
MySQL rămâne incredibil de rapid pentru operații simple de tip read/write. Dacă faci un sistem de blogging, un magazin online clasic sau ceva unde scrii mult și citești rapid după ID, e brici. Am lucrat recent pe un setup cu replication lag aproape de zero pe MySQL, ceea ce e impresionant pentru costuri minime. Dar, sincer, suportul pentru JSON în MySQL încă mi se pare că e pus „cu scoci” față de ce oferă ecosistemul Postgres.
Am avut un caz la un startup de analytics unde am mers pe MySQL din inerție. La 50GB de date, query-urile complexe pe câmpuri dinamice (JSON) au început să ne dea bătăi de cap serioase. Performanța a scăzut brusc și indexarea acelor câmpuri era un coșmar logistic. MySQL e grozav când știi exact structura datelor și nu te abați de la ea, dar devine rigid când vrei să fii „agil” cu date semi-structurate.
Postgres e standardul de facto pentru 2026
Pe de altă parte, Postgres a devenit un fel de sistem de operare pentru date. În 2026, aproape orice SaaS are nevoie de un pic de search sau de vector storage pentru funcționalități AI. Am economisit cam 30% din costurile de infrastructură la un proiect recent pentru că n-am mai ridicat o instanță separată de Pinecone sau Elasticsearch. Am băgat pgvector și pg_search și am rezolvat problema direct în baza de date principală.
Un trade-off sincer? Postgres e mai „pretențios” cu resursele. Dacă vrei să rulezi ceva pe cel mai ieftin VPS de 5 euro, MySQL o să respire mai ușor. Postgres mănâncă RAM la micul dejun dacă nu știi să-i configurezi shared_buffers sau work_mem. Dar, între noi fie vorba, dacă te zgârcești la 10 euro pe lună pentru inima aplicației tale, ai probleme mai mari decât alegerea engine-ului de DB.
Când chiar contează alegerea?
Mai e chestia cu migrațiile de schemă. În Postgres sunt tranzacționale. Asta înseamnă că dacă o migrare crapă la jumătate, nu rămâi cu baza de date într-o stare inconsistentă. La MySQL, m-am fript de câteva ori: un ALTER TABLE a mers, dar următorul a crăpat, și a trebuit să dau rollback manual la tabele la 2 dimineața. Nu e deloc fun.
Totuși, MySQL câștigă la capitolul „developer experience” pentru proiecte mici. E peste tot, orice tool de hosting îl suportă nativ și e mult mai iertător cu conexiunile lăsate deschise (deși acum avem bouncere de conexiuni și pentru Postgres). Dacă ai o echipă care știe MySQL pe de rost, s-ar putea să pierzi mai mult timp învățând nuanțele Postgres decât câștigând din feature-urile lui.
Verdictul meu în 2026? Mergi pe Postgres default pentru orice SaaS nou. E mult mai greu să te muți de pe MySQL pe Postgres când crești, decât invers. Flexibilitatea pe care ți-o dă la început, când încă nu știi exact cum va arăta produsul peste 6 luni, e neprețuită.
Voi pe ce ați mers la ultimul proiect? Ați simțit limitările MySQL-ului la volume mari sau Postgres vi s-a părut overkill pentru un MVP?