DEV Community: mote

I Tried 4 Async Runtimes on a Raspberry Pi — Only One Didn't Make Me Want to Throw It Out the Window

mote — Fri, 17 Apr 2026 12:08:53 +0000

Last month I spent three weeks doing something that sounds simple: making an HTTP client work reliably on a Raspberry Pi 4 running a custom Rust service. The service needed to periodically sync sensor data to a cloud endpoint while also handling local database writes. Nothing fancy — maybe 200 lines of logic.

It took me 2,847 lines of code, 4 different async runtimes, and one very close relationship with my debugger to get it working.

Here's what actually happened.

Attempt 1: Tokio — The Standard Choice

Everyone says "just use Tokio." So I did.

[dependencies]
tokio = { version = "1", features = ["full"] }

On my MacBook, it compiled in 12 seconds and ran perfectly. On the Raspberry Pi? Cross-compilation worked, but the binary was 8.3 MB. For a service that was supposed to be lean and embeddable, that felt wrong.

But the real problem was memory. Under load (simulating 50 concurrent sensor readings + database writes), the RSS crept up to 45 MB. On a Pi with 4 GB of RAM running other services, that's not catastrophic, but it's not great either.

The worst part: I needed a specific timer implementation that played nice with the Pi's real-time clock, and Tokio's time module had a subtle drift that accumulated over 24 hours. We're talking milliseconds becoming seconds. When you're timestamping sensor events, that matters.

Verdict: Works, but it's like using a sledgehammer to hang a picture frame.

Attempt 2: async-std — The Alternative

[dependencies]
async-std = { version = "1", features = ["attributes"] }

async-std felt more ergonomic. The API is closer to what you'd expect from Rust's standard library. File I/O felt more natural. The binary was slightly smaller (7.1 MB).

But then I hit the wall: async-std's networking stack had a bug with DNS resolution on ARM64 that caused a hang every ~6 hours. I found an open issue from 18 months ago with 47 upvotes and no resolution.

I tried patching it myself. That's when I realized I'd rather rewrite the whole thing than debug someone else's async DNS resolver.

Verdict: Promising, but production-unsafe on ARM for anything long-running.

Attempt 3: smol — The Minimalist

smol is beautiful in its simplicity. Small binary (4.2 MB), low memory footprint (22 MB RSS under the same load), and the async-io crate underneath is surprisingly robust.

The problem? Dependency hell. smol uses blocking for sync-to-async bridging, and our database library (SQLite, via rusqlite) kept deadlocking in subtle ways when called from multiple async tasks. The blocking crate's thread pool would exhaust, and then... silence. No error, no panic. Just a service that stopped responding.

I spent two days adding timeout wrappers around every database call before I gave up.

Verdict: Perfect if you control every dependency. We didn't.

Attempt 4: embassy — The Embedded Champion

This is where things got interesting. Embassy isn't really an async runtime in the traditional sense — it's an async framework designed for no_std embedded systems.

[dependencies]
embassy-executor = "0.6"
embassy-time = "0.3"
embassy-net = "0.4"

Wait, can you even run Embassy on a Raspberry Pi? Technically, Embassy targets microcontrollers (STM32, nRF, ESP32). But the networking and I/O abstractions work on Linux too, thanks to embassy-net's socket backend.

The binary was 2.8 MB. Memory usage stayed flat at 15 MB under load. The timer was rock-solid (it uses the hardware timer abstraction, and on Linux it maps to the appropriate clock source).

There was one catch: the learning curve. Embassy's model is fundamentally different. You don't spawn tasks like Tokio — you use Spawner and embassy_executor::main. The networking API expects you to think in terms of TcpSocket objects rather than streams. It took me a full day to restructure the code.

But once it compiled? It just worked. No memory leaks, no timer drift, no DNS hangs, no thread pool deadlocks. 72 hours of continuous testing without a single hiccup.

#[embassy_executor::main]
async fn main(spawner: Spawner) {
    let net = embassy_net::Stack::new(
        &mut net_config,
        &mut rng,
        &mut interface,
    );

    spawner.spawn(sensor_task(net.clone())).ok();
    spawner.spawn(sync_task(net.clone(), db)).ok();
}

The Hard Lesson

Here's what I wish someone had told me before I started:

Binary size matters on edge devices. 8 MB vs 2.8 MB isn't just a number — it's the difference between fitting in a constrained update partition and failing deployment.
Timer accuracy is a silent killer. Most people don't notice until they're correlating events across devices and the timestamps don't line up.
"Standard" runtimes aren't optimized for your hardware. Tokio is amazing for servers. It's not optimized for a $35 ARM board with eMMC storage.
The ecosystem lock-in is real. Your choice of async runtime determines which libraries you can use, how you handle errors, and what your deployment looks like.

What I'm Using Now

For our robotics work at moteDB, we ended up with a hybrid: Embassy for the embedded layer (sensor I/O, real-time control), and a minimal synchronous Rust core for database operations. We intentionally avoided async in the database layer — synchronous code with a dedicated thread is simpler, more debuggable, and has predictable performance characteristics.

Sometimes the best async architecture includes knowing when NOT to be async.

Has anyone else run into the async runtime choice problem on constrained hardware? I'm curious if there are other options I missed — especially anything that bridges the gap between Tokio's ecosystem and Embassy's efficiency.

I Spent 3 Months Tuning a Tokio Runtime for My Robot - Here's What No Tutorial Tells You

mote — Fri, 17 Apr 2026 09:37:50 +0000

Last November, my robot arm started dropping sensor frames at exactly 47ms intervals. Not randomly - exactly 47ms, like clockwork. It would read joint angles perfectly for a while, then miss a window, then recover. The anomaly detector we'd wired into the control loop kept triggering false positives. My teammate Rui and I spent two full weeks convinced the CAN bus driver was broken.

It wasn't the driver.

It was #[tokio::main].

The Setup

We were building an AI-driven robot arm that does pick-and-place with semantic understanding. The control loop needs:

1ms cycle time for joint position updates
10ms window to fuse sensor data before inference
Background persistence - log everything to a local database so we can replay sessions offline

The stack was reasonable: Rust, Tokio for async, a custom message bus, moteDB for embedded storage (vectors + time-series + structured state in one engine). We used #[tokio::main] because that's what every tutorial shows, with a thread pool spawned for the heavy inference work.

It worked great on my laptop. It fell apart on the robot.

What #[tokio::main] Actually Does (And Doesn't Do)

Here is the thing nobody explains in the "Getting Started with Tokio" guides: #[tokio::main] spins up a multi-threaded runtime with a number of worker threads equal to the number of logical CPU cores. On a modern dev machine that's 8-16. On a Raspberry Pi 5? 4 cores - and two of them are already pressured by the camera pipeline and the neural inference engine.

The bigger problem: Tokio's work-stealing scheduler doesn't know anything about real-time priorities. It will cheerfully preempt your 1ms control loop task to service a database flush, a log write, or a DNS resolution that some library decided to make async under the hood.

That 47ms drop? The Tokio scheduler was occasionally parking our sensor polling task while flushing a batch write to moteDB. The flush was async, perfectly polite, and completely invisible in any standard profiling tool because it showed up as I/O wait rather than CPU time.

The Fix: Surgical Runtime Configuration

Instead of #[tokio::main], we switched to:

fn main() {
    let control_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(1)
        .thread_name("control-loop")
        .thread_priority(ThreadPriority::Max)  // with tokio-runtime-extensions
        .build()
        .unwrap();

    let io_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(2)
        .thread_name("background-io")
        .build()
        .unwrap();

    control_rt.spawn(async move {
        run_control_loop().await;
    });

    io_rt.block_on(async move {
        run_support_tasks().await;
    });
}

Two runtimes. The control loop never shares a thread pool with storage I/O or inference scheduling. After this change, our 47ms drops disappeared entirely.

Three Things I Wish Someone Had Told Me

1. spawn_blocking is not free

Every call to spawn_blocking steals a thread from a shared blocking thread pool (default: 512 threads). If you're calling it in a tight loop for sensor serialization, you will exhaust the pool under load. We switched to dedicated std::thread::spawn for our serialization hot path and kept spawn_blocking only for true one-offs.

2. Async mutex is slower than you think at high frequency

tokio::sync::Mutex parks the task and hands control to the scheduler when it contends. At 1ms cycle time, this is catastrophic. For shared state between the control loop and the storage layer, we used std::sync::Mutex - a blocking primitive - because the lock hold time was microseconds and the task switch overhead of the async version was larger.

3. The database write path must not block the runtime

This is where moteDB's design helped us: writes are append-only to a WAL first (sub-microsecond), with the actual B-tree / vector index update deferred to the background runtime. If your embedded database does synchronous index updates on every write, you will feel it in your control loop latency. The write path and the read path need different scheduling contracts.

The Bigger Pattern

Embedded AI systems are not web servers. On a web server, a 50ms hiccup on one request is invisible to other requests. On a robot, a 50ms hiccup in your control loop is a dropped object, a wrong turn, or a crash.

The #[tokio::main] default was designed for web services where fairness across tasks is the right trade-off. For real-time embedded work, you need:

Isolation: critical tasks on dedicated runtimes
Priority: OS-level thread priorities for the control loop
Non-blocking storage: a database whose write path does not block the scheduler

We ended up with a three-layer architecture: hard real-time control loop, soft real-time sensor fusion + inference, and best-effort persistence and telemetry. Each layer has its own Tokio runtime, and they communicate via lock-free channels (tokio::sync::mpsc with bounded capacity).

The 47ms drops are gone. We have been running stable for three months.

TL;DR

#[tokio::main] is fine for most things. For embedded real-time, it is a footgun.
Use separate tokio::runtime::Builder instances to isolate critical paths.
std::sync::Mutex beats tokio::sync::Mutex when lock hold time is microseconds.
Make sure your storage layer (whatever it is) has non-blocking write semantics.

Has anyone else hit scheduler interference issues in embedded Rust? I'm curious whether the community has converged on better patterns here - or whether this is still a "figure it out yourself" problem.

I Spent 3 Months Tuning a Tokio Runtime for My Robot — Here's What No Tutorial Tells You

mote — Fri, 17 Apr 2026 09:31:04 +0000

I Spent 3 Months Tuning a Tokio Runtime for My Robot — Here's What No Tutorial Tells You

Last November, my robot arm started dropping sensor frames at exactly 47ms intervals. Not randomly — exactly 47ms, like clockwork. It would read joint angles perfectly for a while, then miss a window, then recover. The anomaly detector we'd wired into the control loop kept triggering false positives. My teammate Rui and I spent two full weeks convinced the CAN bus driver was broken.

It wasn't the driver.

It was #[tokio::main].

The Setup

We were building an AI-driven robot arm that does pick-and-place with semantic understanding. The control loop needs:

1ms cycle time for joint position updates
10ms window to fuse sensor data before inference
Background persistence — log everything to a local database so we can replay sessions offline

It worked great on my laptop. It fell apart on the robot.

What #[tokio::main] Actually Does (And Doesn't Do)

Here is the thing nobody explains in the "Getting Started with Tokio" guides: #[tokio::main] spins up a multi-threaded runtime with a number of worker threads equal to the number of logical CPU cores. On a modern dev machine that's 8-16. On a Raspberry Pi 5? 4 cores — and two of them are already pressured by the camera pipeline and the neural inference engine.

The Fix: Surgical Runtime Configuration

Instead of #[tokio::main], we switched to:

fn main() {
    // Dedicated 1-thread runtime for the control loop
    let control_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(1)
        .thread_name("control-loop")
        .thread_priority(ThreadPriority::Max)  // with tokio-runtime-extensions
        .build()
        .unwrap();

    // Separate runtime for background I/O (storage, logging, telemetry)
        let io_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(2)
        .thread_name("background-io")
        .build()
        .unwrap();

    // Spawn control loop on dedicated runtime
    control_rt.spawn(async move {
        run_control_loop().await;
    });

    // Spawn storage + inference on IO runtime
    io_rt.block_on(async move {
        run_support_tasks().await;
    });
}

Two runtimes. The control loop never shares a thread pool with storage I/O or inference scheduling. After this change, our 47ms drops disappeared entirely.

Three Things I Wish Someone Had Told Me

1. spawn_blocking is not free

2. Async mutex is slower than you think at high frequency

tokio::sync::Mutex parks the task and hands control to the scheduler when it contends. At 1ms cycle time, this is catastrophic. For shared state between the control loop and the storage layer, we used std::sync::Mutex — a blocking primitive — because the lock hold time was microseconds and the task switch overhead of the async version was larger.

3. The database write path must not block the runtime

The Bigger Pattern

The #[tokio::main] default was designed for web services where fairness across tasks is the right trade-off. For real-time embedded work, you need:

Isolation: critical tasks on dedicated runtimes
Priority: OS-level thread priorities for the control loop
Non-blocking storage: a database whose write path does not block the scheduler

The 47ms drops are gone. We have been running stable for three months.

TL;DR

#[tokio::main] is fine for most things. For embedded real-time, it is a footgun.
Use separate tokio::runtime::Builder instances to isolate critical paths.
std::sync::Mutex beats tokio::sync::Mutex when lock hold time is microseconds.
Make sure your storage layer (whatever it is) has non-blocking write semantics.

Has anyone else hit scheduler interference issues in embedded Rust? I'm curious whether the community has converged on better patterns here — or whether this is still a "figure it out yourself" problem.

I Stopped Treating My AI Agent's Memory Like a Log File

mote — Thu, 16 Apr 2026 11:20:00 +0000

Last year, I spent two weeks debugging why my robot kept repeating the same mistake.

Not a code bug. Not a hardware failure. The robot knew what it had done wrong the last time. I could see it in the logs. It had stored the error. It just didn't... use that knowledge when the same situation came up again.

That's when I realized I had been solving the wrong problem.

The Log File Mental Model

Most agent memory systems I've seen follow the same pattern:

Agent does something
Store a text description of what happened
Later, embed it and retrieve it with semantic search
Inject retrieved context into the next prompt

It's elegant. It works well for conversational AI — the kind that lives in a chat window and helps you write emails.

But I'm building robots. And the log-file model breaks in ways that aren't obvious until your robot crashes into the same wall for the third time.

Here's why.

What Goes Wrong on the Edge

A robot's environment produces data that doesn't fit in a text string.

When my drone hit an airflow problem near a building edge, what it experienced was:

A 47ms IMU reading spike (accelerometer Z-axis: +3.8g)
A camera frame showing a glass surface at 0.4m
A motor throttle log
A GPS coordinate
A vibration frequency pattern

I stored a text note: "Building edge caused unexpected turbulence, compensated with throttle adjustment."

Two weeks later, same building edge. The agent retrieved the text note. The text said "throttle adjustment." The agent adjusted throttle. It still struggled, because the actual recovery wasn't about throttle — it was about yaw correction combined with a specific altitude hold. The text summary had lost the operational precision.

This is the binding problem. The memory exists. The retrieval works. But the stored representation can't carry the real-world nuance.

What Memory Actually Needs to Do (For Agents That Act)

After a lot of iteration, I've landed on a different model:

Memory for acting agents is not a recall system. It's a structured experience index.

That means:

Multi-modal by default. An experience in the physical world involves sensor readings, visual data, timing, and spatial context — not just a text description of what happened.
Queryable by context, not just keywords. "What did I do last time the accelerometer reading was above 3g near a glass surface?" is a different query than "what happened near buildings?"
Lightweight enough to run on the device. A Raspberry Pi can't afford 500ms vector search round-trips mid-flight.
Persistent across power cycles. Edge AI devices reboot. Memory has to survive that.

None of the existing options — SQLite, Redis, Chroma, even small embedded vector stores — were designed for this combination.

What I Built Instead

I spent about four months building moteDB, a Rust-native embedded database specifically for this use case.

The core design decisions:

1. Multi-modal storage as a first-class concept.
A "record" can contain a vector, a binary blob, structured fields, and a timestamp — not an ORM abstraction on top of text columns. When the drone stores an experience, it stores all modalities together, not in separate tables that need joining later.

2. No runtime dependencies.
cargo add motedb — that's it. It runs in the same process as your agent. No daemon, no network round-trip, no container to manage.

3. Designed for embedded constraints.
Memory budget is explicit. Old records get evicted by policy. It doesn't assume you have 32GB of RAM or SSD storage.

4. Query by structured context.
You can ask: "Give me the 3 most similar past experiences where sensor reading X was above threshold Y and the outcome was Z." That's a spatial + vector + structured query — all in one call.

Does It Actually Help?

The real test: same building edge, three months after I started using moteDB.

The drone recalled the actual IMU trace from the previous incident — not a text summary of it. Its flight controller could compare the current sensor pattern directly to the stored pattern. Yaw correction happened 400ms earlier than it had previously.

No crash.

More importantly: I didn't have to rewrite the memory system every time the robot encountered a new type of sensor data. The schema is flexible. Text, vectors, binary — it stores what the agent actually experiences.

The Broader Point

The "agent memory = semantic text search" assumption works for chat-based agents because their world is text. But if you're building agents that act in physical or structured-data environments, the mismatch compounds fast.

The memory system needs to match the modality of the environment, not just the modality of the LLM interface.

I'm still iterating on this. The drone problem is mostly solved. The harder one is multi-agent memory sharing — when two robots have different experiences of the same environment, how do you merge those sensibly?

Working on it.

If you're building agents that operate in physical or data-heavy environments, I'd be curious what memory architecture you're using. Are you hitting the same log-file limitation, or have you found something that works well?

cargo add motedb if you want to experiment. GitHub: https://github.com/motedb/motedb

I Spent 3 Months Tuning a Tokio Runtime for My Robot — Here's What No Tutorial Tells You

mote — Mon, 13 Apr 2026 10:20:41 +0000

I Spent 3 Months Tuning a Tokio Runtime for My Robot — Here's What No Tutorial Tells You

It wasn't the driver.

It was #[tokio::main].

The Setup

We were building an AI-driven robot arm that does pick-and-place with semantic understanding. The control loop needs:

1ms cycle time for joint position updates
10ms window to fuse sensor data before inference
Background persistence — log everything to a local database so we can replay sessions offline

It worked great on my laptop. It fell apart on the robot.

What #[tokio::main] Actually Does (And Doesn't Do)

Here is the thing nobody explains in the "Getting Started with Tokio" guides: #[tokio::main] spins up a multi-threaded runtime with a number of worker threads equal to the number of logical CPU cores. On a modern dev machine that's 8-16. On a Raspberry Pi 5? 4 cores — and two of them are already pressured by the camera pipeline and the neural inference engine.

The Fix: Surgical Runtime Configuration

Instead of #[tokio::main], we switched to:

fn main() {
    // Dedicated 1-thread runtime for the control loop
    let control_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(1)
        .thread_name("control-loop")
        .thread_priority(ThreadPriority::Max)  // with tokio-runtime-extensions
        .build()
        .unwrap();

    // Separate runtime for background I/O (storage, logging, telemetry)
        let io_rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(2)
        .thread_name("background-io")
        .build()
        .unwrap();

    // Spawn control loop on dedicated runtime
    control_rt.spawn(async move {
        run_control_loop().await;
    });

    // Spawn storage + inference on IO runtime
    io_rt.block_on(async move {
        run_support_tasks().await;
    });
}

Two runtimes. The control loop never shares a thread pool with storage I/O or inference scheduling. After this change, our 47ms drops disappeared entirely.

Three Things I Wish Someone Had Told Me

1. spawn_blocking is not free

2. Async mutex is slower than you think at high frequency

tokio::sync::Mutex parks the task and hands control to the scheduler when it contends. At 1ms cycle time, this is catastrophic. For shared state between the control loop and the storage layer, we used std::sync::Mutex — a blocking primitive — because the lock hold time was microseconds and the task switch overhead of the async version was larger.

3. The database write path must not block the runtime

The Bigger Pattern

The #[tokio::main] default was designed for web services where fairness across tasks is the right trade-off. For real-time embedded work, you need:

Isolation: critical tasks on dedicated runtimes
Priority: OS-level thread priorities for the control loop
Non-blocking storage: a database whose write path does not block the scheduler

The 47ms drops are gone. We have been running stable for three months.

TL;DR

#[tokio::main] is fine for most things. For embedded real-time, it is a footgun.
Use separate tokio::runtime::Builder instances to isolate critical paths.
std::sync::Mutex beats tokio::sync::Mutex when lock hold time is microseconds.
Make sure your storage layer (whatever it is) has non-blocking write semantics.

I Replaced SQLite with a Rust Database in My AI Robot — Here's What Happened

mote — Mon, 13 Apr 2026 01:36:15 +0000

I used SQLite for everything.

For years, it was my default answer to "where do I store stuff." Config files, sensor logs, user data, even model outputs — SQLite handled it. When I started building an AI-powered robot that needed on-device memory, the choice felt obvious: embed SQLite, done.

Three weeks later, the robot's memory was a mess of incompatible schemas, I was writing custom serialization code for every data type, and I'd accumulated roughly 400 lines of glue code just to store and retrieve things that weren't text or numbers. Image embeddings. Audio fingerprints. Sensor state vectors.

That's when I started questioning whether SQLite was actually the right tool for this problem, or just the familiar one.

What AI Agents Actually Need to Remember

Here's the thing about robot memory that isn't obvious until you're building it: AI agents don't remember rows of data. They remember moments — multimodal snapshots of state.

A moment might be:

A 512-dimensional face embedding from the camera
A timestamp
An associated audio clip (4KB PCM)
A confidence score
A label ("this is the owner")

In SQLite, storing this requires: a TEXT field for the embedding (serialized JSON or base64), a BLOB for audio, two REAL fields, and a TEXT field. Then on retrieval, you deserialize everything back. For one record, fine. For 10,000 records when you need to find the 5 most similar faces to the one in the current frame? Now you're loading blobs you don't need, deserializing vectors you'll immediately re-encode for comparison, and doing similarity math in Python one row at a time.

I was making SQLite solve a problem it wasn't designed for.

The Real Performance Problem

Let me share the actual numbers from my setup (Raspberry Pi 5, 8GB RAM):

SQLite approach:

Store a face embedding (512-dim float32 array): ~2.1ms avg
Find top-5 similar faces in corpus of 1,000 records: ~340ms (full scan + Python cosine similarity)
RAM overhead for 1,000 embeddings loaded for comparison: ~180MB

The problem: 340ms for recognition is perceptible. A robot that pauses for a third of a second to recognize someone it's seen before feels broken. And 180MB just for embeddings in a device with 8GB — fine now, but what happens at 10,000 records?

The bottleneck wasn't SQLite being slow at SQL. It was SQLite being the wrong abstraction for vector similarity search.

Enter moteDB

I started working on moteDB after hitting this wall. The design goal was narrow: an embedded database written in Rust that handles multimodal data natively and makes vector search a first-class operation, specifically on edge/IoT hardware.

The core difference from SQLite is the data model. Instead of tables and rows, moteDB stores fragments — typed data units that can be embeddings, blobs, scalars, or structured records. A "memory" is a collection of fragments with a timestamp and context metadata. Vector search operates on embedding fragments directly without deserialization.

# Cargo.toml
[dependencies]
motedb = "0.1.6"

use motedb::{Mote, Fragment, VecQuery};

// Store a face recognition moment
let mote = Mote::new()
    .fragment(Fragment::embedding("face", &embedding_512d))
    .fragment(Fragment::blob("audio_clip", audio_bytes))
    .fragment(Fragment::scalar("confidence", 0.94))
    .label("owner");

db.insert(mote)?;

// Find top-5 similar faces
let results = db.search(VecQuery::new("face", &current_embedding).top_k(5))?;

Same logical operation. No serialization. No schema definition. No glue code.

The Numbers After Switching

Running the same Raspberry Pi 5 benchmarks:

moteDB approach:

Store a face embedding: ~0.3ms avg
Find top-5 similar in 1,000 records: ~8ms
RAM for 1,000 embeddings active index: ~22MB

The 340ms → 8ms improvement on search is the one that changed the robot's behavior. Recognition went from perceptible pause to imperceptible. The 180MB → 22MB improvement means I can scale to 10x the memory corpus before hitting constraints.

Are these dramatic numbers? Yes, but the comparison is a bit unfair — SQLite is doing general-purpose relational work, moteDB is doing one specific thing. The point isn't "moteDB is faster than SQLite," it's that you're comparing apples to purpose-built apples.

When SQLite Is Still the Right Answer

This isn't an "SQLite is bad" post. SQLite remains the right choice for:

Config and settings storage — nothing beats SQLite's simplicity for "remember this preference"
Relational queries across structured data — if your data is naturally tabular with joins, use SQL
Maximum ecosystem compatibility — SQLite has bindings in every language, tooling everywhere
Audit logs and event history — append-only structured records are exactly what SQLite is great at

The switch to moteDB made sense for my use case because my data was fundamentally multimodal and similarity search was a core operation. If I'd been building a robot that needed to remember facts and query them relationally ("what's the last time I saw Alice?"), SQLite would have been fine.

The Real Lesson

I wasted three weeks because I reached for the familiar tool instead of asking what the problem actually required. SQLite is excellent — but "excellent general-purpose database" and "right tool for AI agent memory" are different things.

If you're building AI systems that work with embeddings, sensor data, and multimodal inputs — especially on edge hardware — the database choice deserves more deliberate thought than it usually gets. The ecosystem defaults (SQLite, PostgreSQL with pgvector) work, but they're not optimized for this access pattern.

I'm curious: what are others using for on-device AI memory storage? Have you hit similar schema/performance walls, or found ways to make SQLite work cleanly with embedding data?

moteDB is open-source and written in Rust. If you're working on edge AI and want to try it: cargo add motedb. GitHub: motedb/motedb

Your Robot Doesn't Need a Vector Store — It Needs a Memory System

mote — Sun, 12 Apr 2026 23:40:22 +0000

Last Tuesday, our robot walked into the kitchen for the 31st time that week. Same route. Same question: "What should I prepare for lunch?"

It had already asked that question. And answered it. And remembered the answer â€” for exactly 8 hours, until the vector store's TTL kicked in and silently wiped it clean.

That's when I understood: vector databases are solving the wrong problem for embodied AI.

The Semantic Search Trap

Vector databases are brilliant at one thing: finding similar things. "Show me documents about cooking." "Find images that look like this." Great. Wonderful.

But a robot standing in a kitchen isn't asking semantic questions. It's asking:

"Have I been here before?" (spatial + temporal)
"How long has the stove been on?" (time-series)
"Is this object in the same position as last time?" (structured state)

Vector similarity can't answer any of these. You need a database that thinks in sequences, timestamps, and relationships â€” not just embeddings.

What Robots Actually Need

After 3 months of building memory systems for autonomous robots, here's what actually matters:

1. Temporal continuity. A robot doesn't just need to know what happened. It needs to know when it happened and in what order. Did the person enter before or after the door opened? Vector stores have no concept of time.

2. Spatial context. "Kitchen" isn't a semantic cluster â€” it's a location with boundaries, objects, and states. Storing "kitchen" as a vector means you can find similar contexts, but you can't answer "has this specific kitchen been visited in the last hour?"

3. Structured state. The stove's temperature. The door's position. The battery level. These are key-value pairs that change over time and need to be queried efficiently without converting everything into vectors.

4. Multimodal fusion. Sensor data, LLM outputs, camera frames â€” all need to be stored together and queried across modalities.

The Hybrid Stack Problem

The industry answer to this is usually: "Use a vector DB for embeddings + Redis for caching + InfluxDB for time-series + PostgreSQL for state."

That's 4 databases. 4 connection pools. 4 failure modes. And about 50ms of latency per query on a good day.

For a robot making decisions in real-time, that's not engineering â€” that's architectural debt.

A Better Approach: Embedded Multimodal Storage

The alternative is a single embedded database that handles all of these natively:

use motedb::{Database, Store};

let db = Database::open("robot_memory.motedb")?;

let visit = db.store("visits").insert(serde_json::json!({
    "location": "kitchen",
    "timestamp": Utc::now(),
    "robot_id": "unit_7",
    "duration_seconds": 342
}))?;

db.store("sensors").upsert("stove_temp", serde_json::json!({
    "value": 187.5,
    "unit": "celsius",
    "last_updated": Utc::now()
}))?;

let recent = db.store("visits")
    .query()
    .filter(|v| v["location"] == "kitchen")
    .filter(|v| v["timestamp"] > Utc::now() - Duration::hours(1))
    .first()?;

No separate services. No network calls. No latency budget eaten by database round-trips.

The Real Insight

Vector databases are infrastructure for retrieval. Robots need infrastructure for memory.

Memory isn't just "find the most similar thing." It's: what happened, when, where, and how does it affect what happens next?

That's a fundamentally different data problem. And it's why the next generation of embedded databases â€” built in Rust, designed for edge AI â€” are approaching it differently.

What's your experience with robot memory systems? Do you use separate databases for different data types, or have you found a better unified approach?

I Watched My Robot Forget Everything 47 Times a Month — Until I Moved Memory to the Edge

mote — Sun, 12 Apr 2026 13:41:16 +0000

Last Tuesday, my robot was halfway through cleaning the kitchen when the WiFi died.

Not a big deal, right? Except my robot had "outsourced" its memory to the cloud three years ago — and now it didn't know where the trash can was. It asked me. Three times. In the same spot.

"That's not a robot," I thought. "That's a very expensive Roomba with amnesia."

This is the story of how I stopped sending my robot's brain to the cloud — and what I learned about embedded memory along the way.

The Cloud Memory Trap

Here's what most robot builders do: every time the robot sees something interesting, it sends data to the cloud. "Kitchen counter, timestamp 14:32." "Coffee mug, moved." "User preferences, 3rd interaction."

This works great in the lab. You have perfect WiFi. Low latency. Your cloud service scales infinitely.

But real-world robots don't live in labs.

They live in:

Basements with dead zones
Warehouses with interference
Outdoor environments with spotty coverage
Moving vehicles that lose connection constantly

When your robot's "memory" lives in the cloud, every WiFi hiccup becomes a cognitive reset.

I watched my robot "forget" its entire map 47 times in one month. Each time, it had to relearn the layout from scratch. Each time, it bumped into the same table it had mapped 46 times before.

The Embedded Database Experiment

So I did what any frustrated engineer does: I integrated an embedded database that runs directly on the robot's onboard computer.

No network calls. No latency. No "connection refused" errors.

use motedb::{Database, Store};

// Initialize local memory store
let db = Database::new("/robot/brain/memory.db")?;
let store = Store::new(&db)?;

// Robot learns: kitchen counter is at position (2.3, 1.8)
store.insert("location:kitchen_counter", json!({
    "position": [2.3, 1.8],
    "first_seen": "2024-03-15T14:32:00Z",
    "visits": 1
}))?;

Now when the robot enters the kitchen, it checks local memory first. No WiFi required. The data is always there, always accessible, always fast.

The difference was immediate: 200ms to query local memory versus 800ms to cloud and back. And zero failures when the network dropped.

What I Learned (The Hard Way)

After six months with embedded memory running in production, here's what I've learned:

1. Latency Kills Robot UX

A robot that pauses to "think" (i.e., wait for cloud) feels broken. Users don't know it's a network issue — they think the robot is stupid.

With local memory, queries take milliseconds. The robot responds instantly. It feels smart.

2. Edge Computing Isn't Just for AI Models

Everyone talks about running AI models at the edge. But the boring stuff matters too: storing state, remembering context, persisting learned information.

If your robot can't remember where it left off without calling home, it's not truly autonomous.

3. Embedded Databases Are Finally Good Enough

Three years ago, I tried SQLite for this. It worked, but lacked features I needed: time-series support, vector similarity search, ACID transactions for concurrent access.

Now there are purpose-built embedded databases for robotics. Rust-native, no dependencies, single binary. The ecosystem has matured significantly.

4. Offline-First Changes Everything

Once your robot doesn't depend on the cloud for memory, interesting things happen:

It works in places with no connectivity
It responds faster (no round-trip latency)
It's more private (data stays on-device)
It scales differently (no server costs per robot)

You start thinking about robots as truly independent agents rather than thin clients to a central brain.

The Cloud Still Has Its Place

I'm not saying clouds are bad. Clouds are great for:

Fleet-wide analytics
Training data collection
Remote debugging
Cross-robot coordination

But the robot's moment-to-moment memory? That should live on the robot.

It's like asking a human to cloud-source their short-term memory. "Hold on, let me check the cloud what I was doing." Awkward, slow, and occasionally catastrophic.

What Would You Do?

I'm curious about how others handle this problem. Do you run memory entirely on-robot? Hybrid approach? Full cloud?

For robotics use cases where reliability matters more than centralized intelligence, I'm convinced embedded is the way forward.

What's your experience with robot memory architectures? Let me know in the comments.

If you're building a robot and want to experiment with embedded multimodal storage, check out moteDB — it's Rust-native and designed exactly for this use case.

My Drone Flew 5 Minutes Before Its Brain Crashed — Every Single Time

mote — Sun, 12 Apr 2026 07:04:42 +0000

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?

My Drone Flew 5 Minutes Before Its Brain Crashed

mote — Sun, 12 Apr 2026 07:03:40 +0000

My Drone Flew 5 Minutes Before Its Brain Crashed

A true story

The first 47 times my drone crashed.

What Was Actually Happening

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 have missed 5 sensor readings.

My Robot Said Kitchen 47 Times — And Never Knew It Had Already Been There

mote — Sun, 12 Apr 2026 06:46:13 +0000

My Robot Said Kitchen 47 Times — And Never Knew It Had Already Been There

Last Tuesday, my robot announced Entering kitchen for the 47th time. Same kitchen. Same Tuesday. Same confused voice.

Id given it a state-of-the-art vector database. Semantic search. Cosine similarity. The whole thing.

What I hadnt given it? The ability to remember when it last visited the kitchen. Or how long it stayed. Or whether the coffee machine was already on.

The robot knew what a kitchen felt like — but it had no memory of actually being there.

This is the gap nobody talks about.

The Vector Search Trap

Every AI robotics tutorial starts the same way: Store your robots experiences as vectors. Use similarity search to find relevant memories.

Its not wrong. Vector search is incredible. But it creates a specific, subtle failure mode that only shows up when your robot encounters the same situation twice.

The robot thinks every kitchen is the same kitchen.

When the robot asks the vector database for the closest kitchen memory, it gets back a description of a past visit — but not the actual temporal or spatial context of what happened. In robotics, context is everything.

The Three Things Vector Search Cant Tell You

1. When Did This Actually Happen?

Semantic similarity doesnt preserve time. The kitchen from last week looks identical to the kitchen from last year — unless you manually tag timestamps on every embedding.

But even if you add timestamps, you now have to filter by time before you search semantically. Two separate operations. Two different failure modes.

2. How Long Did It Take?

My robot spent 8 minutes in the kitchen last Tuesday. It spent 23 minutes the time before that. It spent 2 minutes the time before that — because it immediately bumped into the dog bowl and panicked.

These durations tell you something important: the robots state was different in each visit. Vector search gives you none of this.

3. Where Exactly In the State Space?

When the robot says kitchen, it doesnt mean just the room. It means proximity to the counter, the refrigerator, whether the stove was on, what the lighting level was, whether the dog was in the room.

These are structured attributes, not vector embeddings.

The Franken-database Problem

So what did I do? I bolted on a time-series database for temporal data. A graph database for spatial relationships. A Redis cache for real-time state.

Five databases. Four different query languages. One robot that still said Entering kitchen 47 times.

The problem wasnt that these tools were bad. The problem was that they werent designed to work together — and robotics requires all of these simultaneously, in real-time, on edge hardware.

What I Actually Needed

I needed one database that could handle:

Vectors — semantic similarity for context matching
Time-series — when did X happen, and for how long?
Structured data — key-value attributes that arent vectors
Single binary — running on a Raspberry Pi, not a data center
Offline-first — the robot cant call home when the WiFi drops

There wasnt anything off-the-shelf. So I built moteDB — a Rust-native embedded database that handles all four data types in a single engine. No server. No cloud. No dependency hell.

The robot now stores location, timestamp, duration, structured state, and embeddings all in one place. One query. All dimensions.

The Question Nobody Asks

We spend so much energy making robots smarter — better models, better sensors, better LLMs.

But maybe the bottleneck isnt intelligence. Maybe its memory.

Not how do I make the robot understand this moment? — but how do I make the robot remember the moments that came before?

Vector search is a powerful tool. But its not a memory system. Its a similarity engine.

What does your robots memory stack look like? Are you using separate tools for vectors, time-series, and structured data — or have you found a better way to unify them?

I Tried 5 Ways to Give My AI Agent Memory (And Built a Database Instead)

mote — Sat, 11 Apr 2026 13:50:55 +0000

Last month, my AI agent forgot a user's name three times in one conversation.

Not a complex name. Not a foreign name. "Sarah." The agent asked "What's your name?" then "Nice to meet you, Sarah" then five minutes later: "Sorry, I didn't catch your name."

Sarah was not impressed. Neither was I.

I had built what I thought was a sophisticated AI system. It could reason, plan, execute tasks. But it had the memory of a goldfish with amnesia.

So I went down the rabbit hole of AI agent memory. I tried everything. Here's what actually workedâ€”and what didn't.

Attempt 1: Just Use the Context Window (Spoiler: It Fails)

My first thought: "LLMs have huge context windows now. I'll just stuff everything in there."

I dumped the entire conversation history into every prompt. Worked greatâ€”for about 10 minutes. Then the context filled up. Older messages got pushed out. Sarah's name was in minute 3. By minute 15, it was gone.

Cost: $0.03 per 1K tokens Ã— 20 turns = expensive amnesia

Latency: 2-3 seconds per response with full history

Reliability: Sarah was still forgotten

Verdict: Context windows are not memory. They're short-term scratchpads.

Attempt 2: SQLite + Manual Prompt Engineering

Okay, I need persistent storage. I'll use SQLiteâ€”it's embedded, it's reliable, it's everywhere.

I built a schema. conversations table. messages table. user_profiles table. Then I wrote code to:

Extract key facts from conversations
Summarize old context
Inject relevant memories into prompts
Manage token budgets

It took three days. It kind of worked. But every new memory type meant schema migrations. Every query meant writing SQL. Every "remember this" feature meant more code.

My agent code was 30% AI logic, 70% database plumbing.

Verdict: SQLite remembers data. It doesn't help your AI use that data intelligently.

Attempt 3: Redis for "Fast" Memory

Someone on Reddit said: "Use Redis for agent memory. It's fast."

Fast, yes. But Redis is a cache, not a memory system. I stored conversation snippets. But Redis doesn't understand meaning. It can't answer: "Has Sarah mentioned she has a dog?" It just stores key-value pairs.

I tried adding vector search on top. Then I had Redis + a vector database + SQLite for persistence. Three systems. Three failure modes. Three things to debug at 2 AM.

Verdict: Fast is useless if it's not smart.

Attempt 4: Pinecone (The Cloud Vector Database)

Vector search! That's what I need. Store embeddings of conversations, search for relevant context.

Pinecone worked. I could find "similar" past conversations. But:

50-100ms latency per query (my agent felt sluggish)
Required internet connection (offline agents = dead agents)
Another external service to manage, pay for, pray stays up
No built-in time-series ("what happened 5 minutes ago?" is different from "what's semantically similar?")

Also, vectors alone aren't enough. I needed the raw text, timestamps, structured state. More glue code. More systems.

Verdict: Cloud vector search is powerful but wrong for embedded agents.

Attempt 5: The Frankenstein Architecture

By this point, my agent's "memory stack" looked like:

SQLite for structured data
Redis for caching
Pinecone for vector search
Custom code to sync them
Custom code to decide which to query when
Custom code to manage consistency

It worked. Sometimes. But adding a new memory type meant touching 4 systems. Debugging meant checking 4 logs. Deploying meant configuring 4 services.

I spent more time on memory infrastructure than on the actual AI.

Verdict: This is insane. There has to be a better way.

The Realization: Agents Need a Memory System, Not a Database

Here's what I learned: AI agents don't just need to store data. They need to:

Store vectors (semantic memoryâ€”"have I seen this before?")
Store time-series (episodic memoryâ€”"what happened when?")
Store state (working memoryâ€”"what am I doing right now?")
Correlate across all three ("when I saw that image, what was my battery level?")
Do it locally (no network, no latency, no cloud dependency)
Do it fast (sub-millisecond queries, not 50ms roundtrips)

No existing database did all of this. So I built one.

Meet moteDB: The Database I Wish Existed

moteDB is an embedded multimodal database for AI agents. It's a single Rust crate. No server. No cloud. No configuration.

cargo add motedb

That's it.

What makes it different?

Vectors + Time-Series + State in one engine

// Store a vector (semantic memory)
let embedding = model.embed("Sarah has a golden retriever named Max");
db.vectors().insert(embedding, metadata)?;

// Store time-series data (episodic memory)
db.time_series().record("user_interaction", timestamp, event)?;

// Store agent state (working memory)
db.state().set("current_user", "Sarah")?;

// Query across all three with logical clocks
let context = db.query()
    .vector_similar_to(current_input)
    .at_time_range(last_5_minutes)
    .with_state("current_user")
    .execute()?;

Sub-millisecond latency

Because it runs in-process, there's no network. The agent calls the database directly. My agent's response time dropped from 2-3 seconds to under 200ms.

Crash-safe by design

Agents crash. Robots lose power. moteDB uses append-only storage with write-ahead logging. When your agent restarts, it remembers exactly where it left off.

Embeddable

No Docker. No Kubernetes. No "just spin up this sidecar." It's a Rust crate that compiles into your agent binary. Runs on Raspberry Pi. Runs on edge devices. Runs anywhere your agent runs.

The Result

Sarah's agent now remembers:

Her name (state)
That she has a dog named Max (vector search finds this in conversation history)
That she prefers evening meetings (time-series pattern: always declines morning invites)
All of this in <10ms, locally, without any cloud calls

The agent feels present. It remembers context. It learns patterns. It doesn't ask "What's your name?" five minutes after you told it.

What I'd Do Differently

If I were starting today, I'd skip attempts 1-5 and go straight to building (or using) a proper agent memory system.

The lesson: Don't glue databases together. Your agent's memory is too important to be an afterthought.

How are you handling agent memory? Are you still stuffing everything into the context window, or have you found something better? I'd love to hear what's working (and what's breaking) in your setups.