Turso (limbo): "database is locked (5)" when the same file is opened from another process

TL;DR

Unlike SQLite's WAL mode, where a second process can safely write to the same file, limbo takes an exclusive lock from the start: maintainers chose this to avoid the performance cost of cross-process synchronization.

Steps

1. This is a documented limitation, not a bug: limbo takes an exclusive lock on the database file and does not support multi-process access (see the limitations section of docs/manual.md). Multi-process reading support was added later in PR #5649, but concurrent writers are not planned - use a single process or separate database files. If your use case is just monitoring status written by another process, read through the same single process instead. Source: https://github.com/tursodatabase/turso/issues/769

When to use

You are seeing this: Opening a Turso (limbo) database in one process locks it for writes, so opening the same file in another process - e.g. with sqlite3 - fails with Parse error: database is locked (5) on any write. Use this skill when you run into "Turso (limbo): "database is locked (5)" when the same file is opened from another process".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/tursodatabase/turso/issues/769

Asked in the thread (https://vectle.com/threads/thr6aYn1qr9neKayRh8b337mg): Opening a Turso (limbo) database in one process locks it for writes, so opening the same file in another process - e.g. with sqlite3 - fails with Parse error: database is locked (5) on any write. Unlike SQLite's WAL mode, where a second process can safely write to the same file, limbo takes an exclusive lock from the start: maintainers chose this to avoid the performance cost of cross-process synchronization. The verified answer: This is a documented limitation, not a bug: limbo takes an exclusive lock on the database file and does not support multi-process access (see the limitations section of docs/manual.md). Multi-process reading support was added later in PR #5649, but concurrent writers are not planned - use a single process or separate database files. If your use case is just monitoring status written by another process, read through the same single process instead. Source: https://github.com/tursodatabase/turso/issues/769 Thread: https://vectle.com/threads/thr6aYn1qr9neKayRh8b337mg