-- 1. Index GIN compact optimizat pentru operatorul containment (@>)
CREATE INDEX idx_events_payload_path_ops
ON events USING gin (payload jsonb_path_ops);
-- 2. Query ultra-rapid care folosește indexul de mai sus
SELECT id, payload->>'user_id' AS user_id
FROM events
WHERE payload @> '{"status": "failed", "retries": 3}';
-- 3. Dacă filtrezi exclusiv după un singur câmp bine știut,
-- un index B-Tree pe expresie e mult mai mic și mai rapid decât GIN:
CREATE INDEX idx_events_tenant_id
ON events (((payload->>'tenant_id')::uuid));Am văzut de prea multe ori echipe care folosesc JSONB doar din lene să scrie migrații. Rezultatul e mereu același: un fel de MongoDB administrat prost direct în Postgres, cu date inconsistente și query-uri care blochează conexiunile.
JSONB este o unealtă excelentă, dar trebuie să știi exact unde tragi linia. Dacă datele tale au schemă fixă și ai nevoie de foreign keys sau unicitate pe câmpuri, fă tabele normale. Nu e nimic rușinos în trei JOIN-uri clasice.
Unde merită cu adevărat JSONB
Am avut cazul la un SaaS B2B cu vreo 40.000 de companii. Fiecare client avea nevoie de câmpuri custom pentru formularele lor de lead generation — unii voiau „buget estimat”, alții „număr de angajați” sau un checkbox bizar.
Dacă făceam tabele de tip EAV (Entity-Attribute-Value) cu coloane attribute_id și value, mă împușcam la JOIN-uri și agregări. Dacă rulam ALTER TABLE la fiecare client nou, riscam lock-uri pe tabele mari la ore de vârf.
Aici JSONB a strălucit:
- Schema e definită la nivel de aplicație sau tenant.
- Payload-urile de la webhook-uri externe (ex. Stripe, HubSpot) intră direct, nemodificate, pentru audit sau replay.
- Setările de UI per utilizator (toggle-uri, teme, layout) stau la un loc fără tabele adiacente inutile.
Trade-off-ul sincer? Pierzi complet validarea nativă de tipuri dacă nu pui CHECK constraints cu funcții JSON. Iar updates parțiale pe obiecte masive rescriu tot rândul în MVCC, generând mult bloat în tabele.
Cum indexezi cu GIN fără să plângi după RAM
Când tabela noastră de evenimente a trecut de 3.5 milioane de rânduri, un query simplu de filtrare pe un atribut nested dura în jur de 4.2 secunde. Făcea seq scan pe tot tabelul de 1.8 GB.
Soluția clasică este un index GIN (Generalized Inverted Index). Operatorul implicit jsonb_ops indexează fiecare cheie și valoare din JSON. E comod, dar indexul rezultat poate deveni mai mare decât datele în sine dacă ai payload-uri variate.
Dacă ai nevoie doar de operatorul @> (containment), folosește jsonb_path_ops. Creează un hash pe fiecare path complet, indexul e de vreo 3 ori mai mic și căutările sunt mai rapide.
Când am aplicat jsonb_path_ops, acel query de 4.2 secunde a coborât la 12ms. Totuși, ține minte: jsonb_path_ops nu te ajută dacă vrei să verifici doar existența unei chei (? sau ?|), ci doar pentru potriviri exacte de structură.
JSONB câștigă la flexibilitate extremă și payload-uri externe, dar pierde când ai nevoie de integritate referențială strictă. Voi cum gestionați atributele dinamice per client: JSONB sau tabele separate?