npm / @mastra/libsql
@mastra/libsql
What changed in @mastra/libsql 1, from its official release notes, upgrade guides and advisories. Sources checked 2026-10-19.
1 breaking3 new APIs and options10 fixes and other
See which of these apply to your code, ranked, in your agent:
npx @unstale/cli init@mastra/libsql 114 changes
Breaking changes 1
libSQL stores reject writes from durable agent executions that lost their run during crash recovery. The claims tables are created on init; with disableInit: true, create them before upgrading. Durable agent runs require the tables to exist.
New APIs and options 3
A nullable supersededBy column is added to the observational memory table automatically at startup and existing rows are backfilled; users managing the schema themselves must add it before upgrading.
Set this option to prune memory run fences when calling storage.prune().
Set this option to prune workflow run ownership claims when calling storage.prune().
Fixes and other changes 10
New tables get a (threadId, id) primary key, and existing tables are upgraded when storage initializes, preventing duplicate notification ids and enabling PostgreSQL updates and deletes in logical replication publications.
Late workflow result writes no longer recreate deleted runs.
Transactions on :memory: databases now commit or roll back like file databases, so partial writes are not left in place when a write fails.
Concurrent reflection, activation, buffering, and message saves no longer lose context or cause SQLITE_BUSY errors on a local file database.
With url plus syncUrl, observational memory writes sync the replica before retrying after a conflict or treating another instance's record as missing; this does not apply to a prebuilt client.
The experimental memory feature was rearchitected.
Reopens connections after a local database write is refused with SQLITE_BUSY, preventing later writes from failing while the connection is stuck.
When multiple LibSQL clients in one process use the same local database file, a write waits for another client's open transaction instead of blocking the process.
Memory writes retry with backoff when another process briefly holds the database lock, using the existing maxRetries and initialBackoffMs options.
Workflow step results can be recorded together with workflow state in a single write, helping evented workflows resume with the correct state after a restart.