On SQLite concurrency: You're absolutely right, SQLite's file-level locking is a real constraint for high-concurrency edge deployments. Rune's answer is multi-database architecture: SQLite is the zero-config local fallback, but PostgreSQL is the production target (Cosmos DB for Azure-native). The connection pool and write patterns abstract this — same binary, config-driven backend. For your robot use case (perception + planning + control loops), you'd want PostgreSQL or the async connection pooling we have in PgPool. We'd love contributions on SQLite WAL mode or read replicas if someone wants to push the embedded story further.
On semantic memory: We're using LanceDB (via lancedb crate) for vector storage, not raw HNSW/IVF. It's columnar, handles hot updates better than flat indices, and plays nice with our local-first requirement. For cold-start, we have explicit memory.level modes: file (scan local session files), keyword (FTS5), and semantic (hybrid with graceful fallback). The real challenge we're wrestling with now is fact deduplication — mem0's update semantics sometimes overwrite instead of merge. That's an active lane if you're interested.
On federated instances: Not CRDTs or event sourcing (yet). Current delegation is imperative with lease-based coordination, main instance picks a peer, reserves a branch/worktree, monitors health, and recovers on timeout. Shared state goes through the REST memory API (/api/v1/memory/*). You're right that conflict resolution is the hard problem, we're moving toward operation-based eventual consistency for vector stores, but right now it's "same user, different devices" rather than true multi-writer federation. We'd love eyes on this — it's genuinely unsolved in the agent space.
Storage layer details: happy to expand, we have rune-store with SQLite (rusqlite), PostgreSQL (sqlx), and Cosmos DB (azure_data_cosmos) implementations. The abstraction is StoreBackend trait, so new backends are ~300 lines.
Thanks for the thoughtful questions
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On SQLite concurrency: You're absolutely right, SQLite's file-level locking is a real constraint for high-concurrency edge deployments. Rune's answer is multi-database architecture: SQLite is the zero-config local fallback, but PostgreSQL is the production target (Cosmos DB for Azure-native). The connection pool and write patterns abstract this — same binary, config-driven backend. For your robot use case (perception + planning + control loops), you'd want PostgreSQL or the async connection pooling we have in PgPool. We'd love contributions on SQLite WAL mode or read replicas if someone wants to push the embedded story further.
On semantic memory: We're using LanceDB (via lancedb crate) for vector storage, not raw HNSW/IVF. It's columnar, handles hot updates better than flat indices, and plays nice with our local-first requirement. For cold-start, we have explicit memory.level modes: file (scan local session files), keyword (FTS5), and semantic (hybrid with graceful fallback). The real challenge we're wrestling with now is fact deduplication — mem0's update semantics sometimes overwrite instead of merge. That's an active lane if you're interested.
On federated instances: Not CRDTs or event sourcing (yet). Current delegation is imperative with lease-based coordination, main instance picks a peer, reserves a branch/worktree, monitors health, and recovers on timeout. Shared state goes through the REST memory API (/api/v1/memory/*). You're right that conflict resolution is the hard problem, we're moving toward operation-based eventual consistency for vector stores, but right now it's "same user, different devices" rather than true multi-writer federation. We'd love eyes on this — it's genuinely unsolved in the agent space.
Storage layer details: happy to expand, we have rune-store with SQLite (rusqlite), PostgreSQL (sqlx), and Cosmos DB (azure_data_cosmos) implementations. The abstraction is StoreBackend trait, so new backends are ~300 lines.
Thanks for the thoughtful questions