June 14, 2026
Delete? More like database drama
The only scalable delete in Postgres is DROP TABLE
Turns out “delete” can make a database do more work, and commenters are fighting about it
TLDR: PlanetScale says deleting tons of records in Postgres can slow everything down, while dropping or emptying a whole table is much more efficient. Commenters split between “this is obvious, use partitions” and “real apps can’t just throw data away that easily,” turning a cleanup tip into a full-on argument.
The big claim from PlanetScale landed like a grenade in database-land: if you need to wipe out huge amounts of data in Postgres, the only thing that really scales is nuking the whole table with DROP TABLE or TRUNCATE instead of deleting rows one by one. In plain English, their point is wild but simple: pressing “delete” on millions of records can actually make the system work harder, not lighter, because the old stuff lingers for a while and the cleanup creates more chores behind the scenes.
And oh, the comments did not stay calm. One camp basically said, “Yes, obviously — this is why smart teams use partitions,” treating the article like a public-service announcement for people who learned this lesson the hard way at 3 a.m. Another group was less impressed and called the headline a little dramatic, with one commenter flatly scoffing that there’s nothing counterintuitive about deletion being expensive. That sparked the classic internet mini-feud: is this a useful reality check for everyday developers, or just old news dressed up as a shocking reveal?
The funniest vibe in the thread is the exhausted, battle-scarred energy. People joked that “delete” is really extra homework for your database, while others warned that real businesses can’t just drop giant chunks of data without accidentally erasing something important. The mood: half nerd lecture, half support group for engineers who have ever watched a cleanup job turn into a disaster movie.
Key Points
- •The article states that large-scale data deletion in Postgres is most scalable when expressed as DROP TABLE or TRUNCATE rather than bulk row DELETE operations.
- •Postgres DELETE operations create dead tuples under MVCC, adding work for readers, autovacuum, and replication instead of immediately reclaiming disk space.
- •DELETE and autovacuum typically only mark storage as reusable within Postgres; returning space to the operating system generally requires VACUUM FULL.
- •The article says index cleanup is not fully performed during DELETE, so later reads and scans may still need to check tuple visibility.
- •DROP TABLE and TRUNCATE are described as scaling largely independently of data size, immediately freeing space and avoiding dead tuples and vacuum debt.