Understanding Database Recovery: Steal and Force Policies Explained

Since last December, I have been leading a database theory book club with some of my software engineering friends. When we reached the chapter on database recovery mechanisms, I found myself struggling to explain the Steal/No-Steal and Force/No-Force policies in a way that resonated with the group. These concepts, while fundamental to database system implementation, can be quite abstract at first encounter.

After the session, I took some time to reflect on better ways to convey these ideas. What if we compared database transactions to something we all use daily? That's when it hit me — collaborative document editing, like Google Docs, provides a perfect analogy for understanding these database recovery policies.

The Collaborative Document Analogy

Before diving into technical details, let's establish our analogy:

Analogy	In DBMS...
Shared document (Google Docs)	The database itself
Individual editors	Separate transactions
Edits appearing in real-time	Data being written to the database
Auto-save functionality	Buffer management and disk writes
"Finished editing" button	Transaction commit
Document history	Transaction log
Final document export	Durable storage

Understanding Steal/No-Steal Policies

Steal Policy

Imagine you're in a meeting where everyone is simultaneously editing the same Google Doc for meeting minutes. When someone adds content, everyone else can see those changes almost immediately, even if the document isn't "finalized" yet.

In database terms, this is a Steal policy, where uncommitted transaction changes can be written to the persistent storage before the transaction completes. The system "steals" the buffer space by writing uncommitted data to disk, usually to free up memory.

Meeting scenario: Alex starts typing the action items but hasn't finished.
Meanwhile, Jamie adds participant names to the document.
Both sets of incomplete changes are visible to everyone and auto-saved
to Google's servers periodically.

Databases with Steal policies need robust recovery mechanisms (like undo logs) because they must be able to revert these "stolen" changes if a transaction aborts.

No-Steal Policy

Now picture a different approach: you designate a single person as the meeting minutes keeper. This person drafts everything in their private workspace, and nobody sees any changes until the minutes are fully completed and officially shared.

This represents a No-Steal policy, where the database guarantees that no uncommitted changes will be written to disk. All modifications stay in memory buffers until the transaction commits.

Meeting scenario: Only the designated note-taker can modify the document.
Everyone else has read-only access. When the meeting ends, the note-taker
reviews everything, makes final edits, and only then shares the completed
document with the team.

A No-Steal policy simplifies recovery (no need for undo operations) but requires more memory since all uncommitted changes must be held in memory until completion.

Steal vs No-Steal: Quick Comparison

Policy	Steal	No-Steal
Memory Usage	Lower (can offload to disk)	Higher (must keep all uncommitted data in memory)
Recovery Requirements	Needs undo log	No undo needed
Buffer Management	More flexible	More constrained
Failure Impact	Must roll back uncommitted disk writes	No uncommitted data on disk
Common Usage	Most production DBMS	Some in-memory databases

Understanding Force/No-Force Policies

Force Policy

After your meeting ends, you might export the final document as a PDF, creating an immutable record that won't change. This deliberate action ensures the document is preserved exactly as it was at that moment.

In database terms, this is a Force policy, where all changes from a transaction must be written to disk before the transaction is considered committed. The system "forces" all modified data to persistent storage at commit time.

Meeting scenario: When the meeting concludes, everyone clicks "Finish" and
the system automatically exports a PDF version of the notes that gets
stored in a dedicated archive folder. Even if the original document
is accidentally deleted later, this exported version remains intact.

Force policies provide stronger durability guarantees because committed transactions are immediately persisted, but they can create performance bottlenecks due to frequent disk I/O.

No-Force Policy

Alternatively, imagine your team continuously updates the same Google Doc week after week for recurring meetings. There's no distinct "finalization" step — the document just keeps evolving, with the system's auto-save feature occasionally backing up the current state.

This represents a No-Force policy, where committed transactions don't have to be immediately written to disk. Instead, modified pages can remain in memory buffers for a while after commit.

Meeting scenario: Your team uses the same living document for all meetings.
Changes are continuously made, and while Google Docs auto-saves periodically,
there's no explicit "finalize and archive" step after each meeting.

No-Force policies typically offer better performance since they reduce immediate I/O operations, but they require redo logs to ensure that committed transactions can be recovered after a system failure.

Force vs No-Force: Quick Comparison

Policy	Force	No-Force
Performance	Lower (waits for disk writes at commit)	Higher (commits don't wait for disk)
Recovery Requirements	No redo needed	Needs redo log
Durability	Immediate	Delayed (until flush to disk)
Commit Speed	Slower	Faster
I/O Pattern	Synchronous at commit	Asynchronous, batched

The Four Recovery Policy Combinations

Real database systems implement combinations of these policies, each with different trade-offs:

1. No-Steal + Force

Analogy: A single note-taker writes everything privately, then exports a final PDF once complete.

Database implementation: Uncommitted changes stay in memory, and all changes are written to disk at commit time.

Characteristics:

• Simplest recovery (no undo/redo needed)
• Highest memory requirements
• Potentially poor performance due to waiting for disk writes
• Used in some in-memory databases and simple embedded systems

2. Steal + Force

Analogy: Everyone can edit in real-time, and the document is exported as a PDF once finalized.

Database implementation: Uncommitted changes may go to disk, and all committed changes are immediately persisted.

Characteristics:

• Requires undo capability for recovery
• More efficient memory usage
• Still has commit-time I/O bottlenecks
• Rare in practice because it combines the complexity of undo recovery with the performance hit of forcing writes

3. No-Steal + No-Force

Analogy: A single note-taker writes everything privately, and the final document remains editable even after being shared.

Database implementation: Uncommitted changes stay in memory, but committed changes don't have to be immediately written to disk.

Characteristics:

• Requires redo capability for recovery
• High memory requirements
• Better commit performance
• Uncommon due to memory constraints

4. Steal + No-Force

Analogy: Everyone edits in real-time, and the document continuously evolves with periodic auto-saves.

Database implementation: Uncommitted changes may go to disk, and committed changes don't have to be immediately written to disk.

Characteristics:

• Requires both undo and redo capability for recovery
• Most efficient memory usage
• Best performance for normal operations
• Most complex recovery mechanism
• Used by most modern DBMS (including PostgreSQL, MySQL's InnoDB)

Why This Matters in Practice

Understanding these policies helps explain why database systems behave the way they do:

1. Recovery time: The policies determine how quickly a database can recover after a crash
2. Memory usage: No-Steal policies require more RAM to hold uncommitted transactions
3. Performance characteristics: Force policies cause more synchronous I/O operations
4. Transaction throughput: The combination of policies affects how many transactions can be processed

Most modern database systems use Steal + No-Force with Write-Ahead Logging (WAL) because it offers the best balance of performance and resource utilization, despite requiring the most complex recovery mechanism.

Conclusion

Remember:

• Steal/No-Steal determines whether uncommitted transactions can write to disk
• Force/No-Force determines whether committed transactions must immediately write to disk
• Most modern databases use Steal + No-Force with robust logging mechanisms