db create --from-file against a TursoDB target: fails after full upload with a generic 502, and leaks an undeletable database

[berenddeboer]

What we were trying to do

Migrate existing Turso Cloud databases onto the new TursoDB (MVCC) engine. Since the engine is chosen at creation time, migration means creating a new database with --tursodb and getting existing data into it. --from-file looked like the natural route.

We now understand that transfer is engine-homogeneous by design — seeding works SQLite→SQLite and TursoDB→TursoDB but not across engines — and we have moved to logical SQL dump and replay, which works correctly. So this is not a request for cross-engine file import. It is about how the unsupported combination fails, and about a resource leak it leaves behind.

What we expected

If --from-file cannot target a TursoDB, the CLI refuses up front with that reason, before uploading anything, and leaves no database behind.

What we tested and saw

Case A — SQLite file into a TursoDB target: fails late, generically, and leaks a database.

sqlite3 seed.db "CREATE TABLE t(id INTEGER PRIMARY KEY, v TEXT); \
                 INSERT INTO t(v) VALUES ('alpha'),('beta');"
sqlite3 seed.db "PRAGMA journal_mode=WAL;"

turso db create demo-a --tursodb --group <group> --from-file seed.db -w

⣾  Validating database file (12.0 KB)...
⣾  Creating database demo-a in group <group>...
Error: could not create database demo-a: could not upload database file:
finalize multipart upload failed with status code 502:
{"error":"upstream forward failed"}

Reproduced twice. The same command without --tursodb succeeds with data intact, so the file and the local validation are fine.

Two problems here:

1. The file is validated and uploaded in full before anything fails, and the failure is a generic upstream infrastructure error. Nothing indicates that the engine is the reason.
2. The failed attempt leaves a database behind that the platform cannot delete. On the second attempt the CLI's own cleanup failed:

failed to delete database: internal server errorError: could not create database demo-b: ...

turso db list then showed demo-b present with TYPE Turso, counting against our database quota. We could not remove it through the CLI.

Case B — TursoDB-native file into either target: client-side parse error.

Given the engine-homogeneous model, we tried a TursoDB-native file, exported from a TursoDB:

turso db export <tursodb-database> --output-file exp.db --overwrite
# Exported database to exp.db      (131072 bytes)

turso db create demo-c --tursodb --group <group> --from-file exp.db -w
turso db create demo-d          --group <group> --from-file exp.db -w

Both fail identically, before any network call:

Error: failed to get file header: bufio.Scanner: token too long

This is arguably correct behaviour — --from-file documents its input as a "SQLite3-compatible file", and a TursoDB export is not one (its header format bytes are 0xFF rather than 0x02). But bufio.Scanner: token too long is an internal parser message, not an explanation. Worth noting the CLI produced this file itself via turso db export, so the two commands are not round-trippable and nothing says so.

How we think it should work

1. Reject the unsupported combination up front. If --from-file cannot target the MVCC engine, fail before validating and uploading, with a message naming the engine — for example, "seeding from a file is not supported for TursoDB databases; use turso db shell <name> < dump.sql".
2. Do not leak databases on a failed create. A create that fails should leave no database, and if cleanup fails the CLI should say which database needs manual removal rather than emitting internal server error.
3. Replace the header parse error with a real message — something like "file is not a SQLite database" — and ideally note that turso db export output cannot be fed back to --from-file.

Point 2 is the one we would prioritise: it is independent of any engine policy, and an undeletable database consuming quota has no workaround from the user side.

Environment

• Turso CLI v1.0.30
• Group version 2026.7.7, primary aws-us-west-2
• Target created with turso db create <name> --tursodb

Possibly adjacent: #1030 concerns the WAL-mode precondition check in the same import path. (We hit that check too — --from-file initially refused our file until we set journal_mode=WAL.)