Turso Tenant Migration Fan-Out
A resumable schema migration fan-out across a fleet of database-per-tenant libSQL databases. Turso makes thousands of databases from one schema parent affordable, which removes the whole class of forgotten WHERE tenant_id clauses, and replaces it with a migration problem: the fan-out is not atomic across databases, so a partial run leaves the fleet at mixed schema versions. Promise.all rejects on the first failure and discards every other outcome; this returns a report naming who reached the target version, who is behind and at what version, and who drifted. Each migration's statements and its ledger row commit in one batch(stmts, write), so libSQL's transactional DDL makes a killed process leave clean ground rather than a schema that moved without its version row, and an explicit write mode avoids the deferred default that loses an upgrade race. A per-version checksum catches an edited migration before it silently splits the fleet into two schemas that both report the same version. Pinned to @libsql/[email protected] and @tursodatabase/[email protected].
npx shadcn@latest add https://ui.aryank.space/r/turso-tenant-migration-fanout.jsonInstalls from ui.aryank.space. To add it by hand, copy the files in Files below, or register the @compronents namespace via the docs.
One tenant was hotfixed by hand during an incident, so migration 3's CREATE TABLE collides there. Promise.all rejects on that first failure and throws away the settled outcome of every other database. The deploy log says the migration failed; it cannot say which of the 10,000 tenants are at v3 and which are at v2, and the application that ships next expects exactly one of them.
@libsql/[email protected]@tursodatabase/[email protected]