# Pornește Prisma Studio pe un port specific dacă ai deja altul deschis
npx prisma studio --port 5555
# Alternativ, în package.json pentru workflow zilnic:
# "studio": "prisma studio"Toată lumea pornește Prisma Studio la primul npx prisma db push. E integrat, pornește într-un tab de browser și își citește configul direct din schema existentă, fără să mai configurezi conexiuni de mână. Totuși, după primele săptămâni într-un proiect serios, o să simți rapid unde i se termină puterile.
Unde strălucește Prisma Studio
Cel mai mare avantaj e simplitatea când lucrezi cu relații. Dacă ai un model User legat de Order și Profile, poți da click direct pe câmpul relațional și ești teleportat în tabela asociată, filtrată deja pe ID-ul respectiv. Pentru navigat rapid prin date relaționale locale, bate orice client SQL clasic unde trebuie să scrii manual un JOIN sau să cauți cheia străină într-un tab separat.
Îl folosesc des când scriu seed-uri sau când fac debugging pe un feature nou de autentificare. Dau un refresh, văd dacă s-a creat rândul în baza de date locală, modific o valoare direct în celulă cu un dublu click și salvez cu Ctrl+S. E perfect și pentru colegii de pe frontend sau QA care nu știu sintaxă de SQL: le pornești studioul local și își pot introduce singuri date de test fără să te bată la cap.
Unde se rupe filmul
Problemele apar când treci de faza de jucărie. La un proiect de e-commerce cu vreo 40k de comenzi pe o instanță locală de Postgres, Studio a început să gâfâie vizibil. A deschis procesul de Node cu un consum de peste 700MB RAM, iar paginarea pe tabele cu multe coloane de tip JSON agăța la fiecare scroll.
Pe lângă performanță, trade-off-ul major e lipsa uneltelor reale de diagnosticare:
- Nu poți rula interogări ad-hoc complexe. Dacă ai nevoie de un
GROUP BYcu agregări pe trei tabele ca să vezi o discrepanță de date, ești blocat. - Nu ai acces la
EXPLAIN ANALYZE. Nu vezi cum funcționează indecșii, ce cost are interogarea sau de ce un query durează 400ms. - Modificările de structură nu se fac de aici. Nu poți altera constrângeri, secvențe sau roluri de utilizatori direct din interfață.
De ce țin TablePlus (sau DBeaver) deschis
Pentru treabă serioasă, prefer TablePlus. E o aplicație nativă, pornește instant și mănâncă cam 45MB RAM indiferent dacă mă uit la zece rânduri sau la un milion. Când am nevoie să optimizez un query generat de Prisma care generează N+1 sub capotă, mă mut direct în TablePlus, scriu SQL nativ și văd exact planul de execuție.
Dacă nu vrei să plătești licența de TablePlus și te enervează limita de două tab-uri deschise simultan din varianta gratuită, DBeaver e alternativa open-source excelentă. E scris în Java, arată mai mult a tool enterprise din anii 2000 și pornește ceva mai greu, dar are absolut tot ce-ți poți dori pe partea de administrare, exporturi mari de date și vizualizare de diagrame ER.
Cum le împart în practică
Regula mea e simplă: folosesc Prisma Studio exclusiv local, pentru verificări de 30 de secunde și navigare prin date legate, în timp ce construiesc schema. Pentru staging, producție, optimizări de indecși sau baze de date cu volume mari, deschid exclusiv TablePlus sau DBeaver.
Voi cum procedați când lucrați cu Prisma — vă bazați pe Studio sau treceți din start pe un client dedicat?