DBMS vs Flat Files Lab (Interactive)
Scan a CSV vs a real DBMS as rows grow, then crash both mid-write. Watch a flat-file sequential scan degrade linearly while a B+Tree index and buffer pool stay flat — then pull the plug and compare corruption against WAL replay.
Why a DBMS Exists: Flat File vs Engine
Same data, same workload — compare lookups, races, and crashes with and without a database engine.
Engine Event Log
How It Works Under the Hood
A file quietly becomes a database the moment you need concurrency, crash safety, and sub-millisecond lookup. A DBMS supplies all three with real subsystems: the buffer pool caches 8KB/16KB pages in RAM, the B+Tree index turns lookups into O(log N) page descents, the lock manager serializes concurrent updates that would otherwise be lost, and the Write-Ahead Log replays committed work after a crash. This lab runs the same workload against both engines so the cost curves and the failure modes speak for themselves.
Core Architectural Principles
- Flat files scan every byte: latency grows O(N) with table size, while a B+Tree index descends in O(log N) page reads served from the buffer pool.
- Concurrent read-modify-write increments on a raw file lose updates; a DBMS lock manager serializes them so all 10 increments survive.
- A crash mid-write corrupts a file with no recovery path, but committed WAL records are replayed after restart with zero data loss.
When asked "why not just files?", name three concrete failure modes: O(N) scans with no index, lost updates under concurrent writes, and unrecoverable partial writes after a crash. Then map each to the DBMS subsystem that solves it — buffer pool and B+Tree, lock manager, and write-ahead log — to show mechanical understanding instead of memorized definitions.
A DBMS buys indexing, transactions, and crash recovery at the price of operational complexity and a small per-write WAL fsync tax.