Building Trauma-Aware Databases: How MindFry Remembers Its Crashes

Introduction

Traditional databases treat crashes as binary events: either you recovered successfully, or you didn't. But what if your database could remember how it failed and adapt accordingly?

In MindFry v1.8.0, we implemented a crash recovery system inspired by biological trauma response. This post explains the engineering decisions behind it.

The Problem

Consider these scenarios:

1. Graceful shutdown — User pressed Ctrl+C, snapshot saved

2. Kill -9 — Process terminated without cleanup

3. Power loss — No warning, no shutdown sequence

4. Long vacation — System off for weeks

A traditional database treats all restarts the same. But cognitively, these are very different events:

Graceful shutdown = Going to sleepKill -9 = Getting knocked outPower loss = Cardiac arrestLong downtime = Coma

The Solution: RecoveryState

We model restart conditions as a tri-state enum:

pub enum RecoveryState {
    Normal,  // Clean restart
    Shock,   // Unclean shutdown detected
    Coma,    // Prolonged inactivity (>1 hour)
}

Detection Algorithm

impl RecoveryAnalyzer {
    pub fn analyze(&self) -> RecoveryState {
        match &self.last_marker {
            None => RecoveryState::Normal, // First run or genesis
            Some(marker) if !marker.graceful => RecoveryState::Shock,
            Some(marker) => {
                let downtime = now() - marker.timestamp;
                if downtime > COMA_THRESHOLD {
                    RecoveryState::Coma
                } else {
                    RecoveryState::Normal
                }
            }
        }
}}

Time complexity: O(1). Just a couple of comparisons.

The Shutdown Marker

Before graceful exit, we write a marker to sled:

pub struct ShutdownMarker {
    pub timestamp: u64,
    pub graceful: bool,
    pub version: String,
}

On startup, we:

1. Read the marker

2. Delete it immediately (so next crash is detected)

3. Analyze the conditions

This "delete on read" pattern ensures:

• If we crash during startup → no marker → next restart = Shock

• If we complete startup → we'll write a new marker on shutdown

Warmup Enforcement

During resurrection (snapshot loading), the database is partially available:

let is_warmup_exempt = matches!(    request,    Request::Ping | Request::Stats);if !is_warmup_exempt && !self.warmup.is_ready() {    return Response::Error {        code: ErrorCode::WarmingUp,        message: "Server warming up - cognitively unavailable".into(),    };}

Why Not Just Block All Requests?

Because health checks (Ping) and monitoring (

Stats) need to work during warmup. Load balancers need to know we're alive.

This is the C17CP principle: Coherence without Interaction.

Performance

All operations are sub-microsecond:

Zero runtime overhead for crash detection.

Future Work

We're exploring:

• Resistance building — System becomes more resilient after crashes

• Temperature tiers — Recovery state affects cognitive sensitivity

• Decay-based resistance — Trauma fades over time

Conclusion

Crash recovery doesn't have to be binary. By treating crashes as cognitive events, we can build databases that:

1. Remember their trauma

2. Adapt their behavior

3. Communicate their state clearly

MindFry v1.8.0 is available on crates.io.

---

Questions? Reach out on GitHub or Twitter.