My Drone Flew 5 Minutes Before Its Brain Crashed — Every Single Time
A true story about why robots shouldn't use SQLite in production
The first 47 times my drone crashed, I blamed the flight controller.
The 48th time, I looked at the logs.
14:32:07 WARNING: Database write latency exceeded 200ms
14:32:08 ERROR: SQLite busy - database is locked
14:32:08 ERROR: Failed to commit sensor data
14:32:09 WARNING: Falling back to in-memory buffer
14:32:11 ERROR: Buffer overflow - oldest data discarded
14:32:12 CRITICAL: Navigation state corrupted
14:32:13 [CRASH]
SQLite. The drone was running SQLite. On a flight-critical system.
What Was Actually Happening
My drone was logging sensor data at 100Hz. Gyroscope, accelerometer, GPS, camera frames, battery state — roughly 2,400 data points per second.
SQLite can handle that. In theory.
In practice, there's a problem: write locking. SQLite uses a single writer lock. When the database is busy committing one transaction, every other write has to wait.
At 100Hz, a 50ms delay means you've already missed 5 sensor readings by the time the write completes. Stack that up over 5 minutes, and you have hundreds of failed writes, a buffer overflow, data gaps that cascade into navigation failures.
This is how database latency becomes crash #48.
The Obvious Fix (That Wasn't)
My first thought: Switch to a faster database. PostgreSQL. TimescaleDB.
So I spun up a TimescaleDB instance on a local server. Pointed the drone at it.
Result: network latency 45-120ms, connection drops every 30 seconds, 6-second data gaps.
Robots don't need cloud databases. They need databases that run on the robot.
What Embedded Actually Means
- Zero setup - no server process, no configuration files
- Single binary - the database is a library you link into your application
- Local storage - everything lives on the device, survives reboots
- Concurrent writes - designed for high-frequency writes without blocking
- Resilient to power loss - crashes don't corrupt data
SQLite handles 1, 2, and 5 beautifully. But it stumbles on concurrent writes under high-frequency sensor workloads.
The solution I eventually landed on: moteDB, designed for high-frequency sensor ingestion on embedded hardware. No server. No WiFi dependency.
The drone flew for 47 minutes on its next flight. First time past the 10-minute mark. No crashes.
The Lesson That Cost Me 48 Crashes
Here's what I should have asked on day one: What happens to my data when the network goes down?
If the answer is the data is lost - you're building the wrong system.
Robots operate in the real world. Networks fail. Servers crash. WiFi drops.
The database should be the last thing that fails, not the first.
Has your project ever had a database crash that cascaded into a bigger failure? Or have you found creative solutions for local-first data on edge devices?