1. Read the source. It's very efficient: https://github.com/postgres/postgres/blob/a14e75eb0b6a73821e0d66c0d407372ec8376105/src/backend/utils/adt/json.c#L285-L3

1. Read the source. It's very efficient: https://github.com/postgres/postgres/blob/a14e75eb0b6a73821e0d66c0d407372ec8376105/src/backend/utils/adt/json.c#L285-L394 https://github.com/postgres/postgres/blob/a14e75eb0b6a73821e... 2. You don't have to do deserialization in the application layer. If all you're using JSON for is to convert to OOP objects, just deserialize in the db -- which again, trivial. 3a. This is wrong on many counts. If you want efficient passing of JSON, use JSONB which is the binary encode of the JSON, as a tree structure. It will not include the structural characters. 3b. Bandwidth is also cheap. 4. Don't optimize without profiling. A few extra CPU cycles is not going to make-or-break your scaling journey, you'll most likely run into larger problems before that happens. 5. You can get "non-uniform" tuples by using UNIONs and a smart flagging system that points to tuple schemas -- rather than using JSON; the difference is entirely ergonomic. 6. If you're in a low-latency environment and the CPU cycles are absolutely critical, write your own extensions to handle what you're trying to do, instead of twisting Postgres into doing your bidding.