Last Tuesday, at 3 AM in a robotics lab that smelled like solder and desperation, my drone — let's call her Doris — smashed into the same wall for the 47th time.
Doris was running a SLAM algorithm. Making real-time navigation decisions. In simulation, she flew beautifully. In the real world, she became a very expensive wall ornament.
The algorithms weren't wrong. The motors weren't bad. The sensors were fine.
The problem? Doris had no memory.
Not "forgot to save" — Doris literally couldn't remember what she'd seen five seconds ago. Each moment was completely isolated. Process a frame, make a decision, next frame, fresh start. Every. Single. Time.
I'm a Rust developer and the founder of moteDB. And watching Doris test the laws of physics 47 times in a row taught me more about what embedded memory for robots actually needs than three years of academic papers.
What AI Robotics Textbooks Get Wrong
Every robotics course talks about world models and semantic memory. Then they tell you to use Redis. Or InfluxDB. Or SQLite + Pinecone.
These solutions assume three things robots don't have:
- Reliable cloud connectivity — aisle 12 has no WiFi
- Tolerance for 50ms+ database latency — at 3 m/s, 50ms is 15cm of blind flight
- A server-grade computer — not every robot has a data center in its belly
What robots actually need is something most databases weren't designed to provide.
The Three Things Robots Need to Remember
1. What they saw — Vectors
Doris's cameras produce 512-dimensional embeddings at 30 frames per second. Over an 8-hour shift, that's 864,000 embeddings. Finding have I seen this place before? requires approximate nearest-neighbor search — but you can't afford a cloud roundtrip at 3 AM.
2. What happened when — Time-Series
Doris's motor draws spiked 340% at the same waypoint three times. That pattern matters. Without temporal context, each incident looks like a new problem. With it, you can predict and avoid.
3. What they're doing right now — State
Doris's battery was at 12%. Her next task required 18% estimated power. Without state, she couldn't make that calculation. Without persistent state, she couldn't survive a reboot.
A real robot memory system has to handle all three. Most databases handle one well and duct-tape the others.
The Actual Number That Made Me Stop Using SQLite
Here's what a face-recognition task looked like on my Raspberry Pi 5 with a corpus of 1,000 embeddings:
| Approach | Recognition Latency | RAM Overhead |
|---|---|---|
| SQLite + Python cosine sim | 340ms | 180MB |
| moteDB (native vectors) | 11ms | 62MB |
340ms is a third of a second. A robot that pauses to recognize someone it's seen before feels broken. And 180MB just for 1,000 embeddings is a rounding error today — but at 100,000 embeddings, it's a different conversation.
The bottleneck wasn't SQLite being slow. It was SQLite being the wrong abstraction for vector similarity search.
What I Built Instead
moteDB is an embedded multimodal database written in 100% Rust. The design constraint was narrow: handle vectors, time-series, and state on edge hardware — no cloud, no server.
The core difference is the data model. Instead of tables and rows, moteDB stores fragments — typed data units where vector search operates directly without deserialization. A robot's memory is a collection of fragments with a timestamp and context metadata.
Installation is cargo add motedb. The Raspberry Pi binary is under 2MB. No runtime dependencies.
Here's What I'd Do Differently
If I were starting over, I'd have asked one question before picking any database:
What happens when this robot loses power at 70% through a task?
If your answer involves it restarts and... — you have a memory problem, not a compute problem. And most databases, no matter how good they are at their primary use case, were never designed to answer that question on a robot.
Doris is flying better now. I can't say the same for my remaining wall plaster.
What's the most frustrating memory-related bug you've hit in an AI or robotics project? Drop it in the comments — I read every one.
Top comments (0)