PlanetScale argues the only scalable delete in Postgres is DROP TABLE

Category: Infrastructure
Status: discussion
Sources: PlanetScale blog, HN discussion
Summary: A PlanetScale engineering post argues that large DELETE statements add work to a Postgres database rather than reclaiming it: deleted rows become dead tuples that still consume space until vacuum runs, indexes are not immediately shrunk, and a big delete generates WAL and vacuum pressure proportional to the rows removed. The recommendation is to structure schemas so removal maps to DROP TABLE or TRUNCATE, for example by partitioning time-series or tenant data so retention becomes dropping whole partitions instead of row-by-row deletes. It surfaced on Hacker News (152 points).
Comments: HN commenters discussed partition-drop retention patterns and noted the same dead-tuple and vacuum cost applies to large updates, not only deletes.
Why it matters: Teams running retention or cleanup jobs as bulk DELETE on large Postgres tables hit MVCC bloat and vacuum load, and partition-drop designs avoid that cost.