Two kinds of people who read this: 1) Ah, good to know, this will prevent me from making mistakes 2) You're telling me there's _never_ a good reason...? Hmmm...
This is wrong. Inexperienced devs should ignore this.
One of my products heavily uses jsonb fields for storing JSON strings from external systems. We have partners that store data as JSON, so we store it as JSON as a kind of untouched log (ELT instead of ETL, I suppose).
If you store a schema somewhere (in, say, JSON Schema format), then your jsonb isn't schema-less when you parse it. Postgres may not understand the schema, but not all of your data transformation is going to happen in Postgres anyway.
Jsonb is also good for caching and logging things like REST request/response bodies if you ever need to query those later.
So in short: if the I/O format is JSON, then jsonb is appropriate.
5 comments
[ 2.8 ms ] story [ 21.5 ms ] threadOne of my products heavily uses jsonb fields for storing JSON strings from external systems. We have partners that store data as JSON, so we store it as JSON as a kind of untouched log (ELT instead of ETL, I suppose).
If you store a schema somewhere (in, say, JSON Schema format), then your jsonb isn't schema-less when you parse it. Postgres may not understand the schema, but not all of your data transformation is going to happen in Postgres anyway.
Jsonb is also good for caching and logging things like REST request/response bodies if you ever need to query those later.
So in short: if the I/O format is JSON, then jsonb is appropriate.