PlanetScale sostiene que, en PostgreSQL, la única estrategia de borrado de datos verdaderamente escalable consiste en eliminar tablas completas mediante DROP TABLE o TRUNCATE, no en borrar filas individuales con DELETE. La afirmación, firmada por el ingeniero Tom Pang, se apoya en el funcionamiento interno del motor: bajo el modelo de control de concurrencia multiversión (MVCC), DELETE no libera espacio físico en disco de inmediato, genera tuplas muertas que el proceso de vacuum debe limpiar después, añade carga de replicación y obliga a los lectores a verificar si cada fila está vigente.
El artículo explica que DROP TABLE y TRUNCATE, aunque requieren un bloqueo AccessExclusiveLock, son prácticamente independientes del volumen de datos: eliminan ficheros del sistema operativo y barren solo las cabeceras de páginas en la caché compartida —64 bytes por cada 8 KB, es decir, 1/128 del tamaño de la caché—, una operación secuencial muy rápida. No producen tuplas muertas, no acumulan trabajo de vacuum y liberan el espacio al sistema de forma inmediata.
Para casos puntuales, como eliminar millones de filas erróneas, los autores proponen abrir una transacción, bloquear la tabla en modo exclusivo, volcar las filas válidas en una tabla temporal, truncar la original y reinsertar los datos conservados. Si el bloqueo prolongado no es aceptable, sugieren replicar escrituras a una tabla nueva y hacer un renombrado atómico, estrategia similar a la que automatiza la extensión pg_squeeze.
Para cargas continuas, recomiendan usar particiones nativas de Postgres, por ejemplo por fecha, de modo que el borrado periódico de datos antiguos se convierta en un DROP TABLE de la partición correspondiente, eliminando de raíz la deuda de vacuum.