hardSystem Design

JSONB vs normalized columns vs EAV — how do you model flexible attributes without killing query performance?

Q: JSONB vs normalized columns vs EAV — how do you model flexible attributes without killing query performance?

Pure `JSONB` is flexible but slower for joins/filters; normalized columns are fastest for hot, query-heavy fields. The **hybrid** model — hot fields as real columns + cold/sparse fields in `JSONB` — wins for most evolving apps. Use `EAV` only for extreme sparsity with typed values. JSONB vs normalized columns vs EAV — pick by query pattern & schema volatility Pure JSONB one jsonb column flexible, schemaless GIN helps but slower joins good for sparse / evo

1.1k views

Understand the problem

Choose between pure JSONB, hybrid (hot columns + JSONB), and normalized/EAV based on query patterns and schema volatility.

jsonbdata-modelingschema-design

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

Study the solution

Pure JSONB is flexible but slower for joins/filters; normalized columns are fastest for hot, query-heavy fields. The hybrid model — hot fields as real columns + cold/sparse fields in JSONB — wins for most evolving apps. Use EAV only for extreme sparsity with typed values.

Solution ready — 2 min read

Classified // press E to declassify

Join the discussion

Discussion (0)

No responses yet. Be the first to share what you think.

Transmission complete // awaiting log

KEEP THE
STREAK ALIVE.

Dossier 53 of 70 decoded in the SQL track. One more won't hurt.

Back to track

Next up→

RANK() vs DENSE_RANK() vs ROW_NUMBER() — when does the gap matter and how do you choose?

Continue