A lot of these functions that we're going to look at, a lot of these operations that we're going to do are JSONB functions. Remember, there's a difference between JSONB and JSON. Many of the functions support both. There's a JSONB version and just a regular JSON version. Not all of them, but I do want to remind you quickly that difference between JSONB and JSON and when you might actually want to reach for JSON instead of JSONB. Quickly, the difference between JSONB and JSON is JSONB stores the JSON on disk parsed.

The JSON comes in from wherever from your application comes in as a string. Postgres will parse it, and then write that binary representation to disc. This gives you a couple things. One, it gives you more overhead. It's going to take up more space. When it does the parsing, it keeps around some extra information about the shape of the object. JSONB is in fact, usually a little bit bigger than just a regular JSON column. However, it is a little bit faster 'cause we don't have to go from text back to that binary representation. It's already in the binary representation. When we're operating on a JSONB document, we don't have to re parse it and therefore, it's a lot faster to traverse, to extract, to update all of that kind of stuff. That's JSONB.

Now, JSON on the other hand, is going to be a little bit more compact and a little bit slower. That's just kind of an opposite of JSONB. Now, why would you ever use JSON over JSONB? You could make the argument that it is more compact. While we do love with our very, very sincerely love compact data types, that argument doesn't move me a whole lot. What does move me is when you parse that JSON document, you lose the exact representation, which might be important. I don't know what your app is, but that might be important. Imagine this. Imagine for some reason, you are relying on the ordering of the keys in a JSON blob. You should not do that. JSON does not guarantee that the keys will be ordered in any language anywhere ever. If you put your JSON blob in a JSON column, you are guaranteed that you can pull it back out in the exact same format with duplicate keys, with keys in a specific order with extra white space. You are guaranteed that that JSON column, whatever you put in, you'll be able to get back out.

On the other hand, whatever you put into a JSONB column is going to be parsed and turned into proper conforming JSON, which may remove white space, rearrange keys, and, of course, remove duplicate keys. A situation where you might go for JSON over JSONB is you need an exact representation of the data. That would be something potentially like logs, something potentially like logs where you need exactly the body of the request that somebody sent you, or you might need the exact body of the response that you sent back out. That might be a pretty good reason.

Another point in that direction is you might not be querying those old logs very often, and so you might not even have a reason to parse it into proper binary representation of JSON 'cause you're basically using it like an append-only logs table. If you ever need it's there, but you're not querying it very often. Maybe the compactness does make sense over there, but at least the exact representation makes sense over there. Those are the kinds of things that you need to consider when you're thinking about JSON versus JSONB, in most cases, I'm going to push you to go to JSONB unless you have a pretty compelling reason of which there are some. Don't hear me say that JSON is bad, but you need to have a pretty good reason to pick JSON over JSONB. Let's look at some JSONB functions.