Course contentsShow
← Databases & SQL
Lesson 661 of 1,9536. Query Performance and IndexingFree lesson

Tombstone Records in Indexes

Understand how logical deletion works in append-only or versioned indexes.

In this lesson, you will learn how databases manage data deletion in append-only or versioned indexes using "tombstones" to maintain performance without immediate data scrubbing.

The Concept of Logical Deletion

In many high-performance database engines, especially those using append-only logs or multi-version concurrency control (MVCC), deleting a record physically from an index is an expensive operation. If the system had to physically remove a row from a balanced tree or a hash map every time a user ran a DELETE command, it would cause massive reorganization overhead, index locking, and fragmented memory pages.

Instead, the database performs a logical deletion. When you delete a record, the system does not immediately remove the index entry. Instead, it marks the record with a "tombstone"—a hidden flag or bit indicating that the row is logically "dead" or deleted, even though it remains physically present in the index structure.

How Tombstones Work

Imagine an index entry that looks like this:

-- Conceptual Index Entry Structure
[SearchKey: 101 | DataPointer: 0xAF23 | IsDeleted: FALSE]

When you execute a DELETE for key 101, the database simply updates the flag:

-- After Logical Deletion
[SearchKey: 101 | DataPointer: 0xAF23 | IsDeleted: TRUE]

When the database engine searches for this key later, it sees the tombstone flag and treats the result as if it were not found. This allows the index to remain physically stable.

Why Use Tombstones?

  1. Efficiency: Marking a bit is near-instantaneous compared to rebalancing an index tree.
  2. Concurrency: By avoiding physical changes, the database avoids holding aggressive locks on index pages, reducing latch contention.
  3. Recovery: Tombstones can sometimes be "undone" during transaction rollbacks, which is much simpler than re-inserting deleted data.

Eventually, a background process—often called a "vacuuming" or "compaction" process—will scan these indexes, physically remove the entries marked with tombstones, and reclaim the space. This separation of concerns allows the system to remain fast during peak query times while cleaning up "dead" records during quieter periods.

Key Takeaway: Tombstone records allow databases to handle deletions as metadata updates rather than expensive structural changes, deferring physical cleanup to a later maintenance task.