What gets TOASTed in Postgres

PostgreSQL’s TOAST mechanism automatically handles oversized variable-length values such as text, jsonb, and bytea once a complete row exceeds roughly 2,032 bytes, first attempting compression and then moving data into an associated TOAST table in chunks when necessary. A value of 2,000 repeated characters can remain uncompressed because its row fits exactly at the threshold, while adding one character can trigger LZ4 compression and reduce it dramatically. TOAST behavior is controlled by column storage strategies, with the usual EXTENDED setting permitting both compression and out-of-line storage, while EXTERNAL avoids compression and MAIN prioritizes keeping data in the main row. PostgreSQL 19 changes the default TOAST compressor from pglz to LZ4 where LZ4 support is available, favoring faster compression and decompression even though pglz can sometimes produce smaller results, particularly for repetitive JSON-like data. LZ4 generally performs better for common workloads and data with repeats farther apart, whereas pglz can efficiently retrieve short prefixes of large compressed values because PostgreSQL can limit how much compressed data it reads. Compression saves storage, cache space, WAL traffic, and backup volume but adds CPU overhead and does not reduce client network output, making EXTERNAL storage preferable for already-compressed files or large binary data requiring efficient random reads. TOAST differs from PostgreSQL large objects by being automatic, limited to 1 GB per value, and deleted with its owning row, while large objects require explicit management and can store up to 4 TB.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.