Damn! So often we treat deletion as something instant, when in practice it behaves more like deferred work that keeps piling up in the background. How do you handle situations where data actually needs to be gone within a strict time window, like for privacy laws, but the system naturally wants to delay deletion to stay stable?
An interesting topic worth checking. But I think even privacy laws won't be able to defy physics, there will always be delays, even if a few hours/milliseconds.
I think b-tree also don’t delete the row immediately. They just mark it as tombstone. In vacuum process it’s cleaned and the space is reclaimed.
It because database use pages to store the data where doing delete immediately need moving the bytes on the pages. There different variants of the b-tree use different approach.
Damn! So often we treat deletion as something instant, when in practice it behaves more like deferred work that keeps piling up in the background. How do you handle situations where data actually needs to be gone within a strict time window, like for privacy laws, but the system naturally wants to delay deletion to stay stable?
An interesting topic worth checking. But I think even privacy laws won't be able to defy physics, there will always be delays, even if a few hours/milliseconds.
I think b-tree also don’t delete the row immediately. They just mark it as tombstone. In vacuum process it’s cleaned and the space is reclaimed.
It because database use pages to store the data where doing delete immediately need moving the bytes on the pages. There different variants of the b-tree use different approach.
Nice read.
Thanks for pointing it out. It reinforces that nothing is deleted immediately.