#9094·turso

A WITHOUT ROWID table whose PRIMARY KEY is not the first column is stored in a layout SQLite cannot use

Author: LeMikaelFCreated Sep 16, 2026Updated Sep 16, 2026
Labelscompatibilitycorrectness

turso stores the rows of a WITHOUT ROWID table in schema order. SQLite stores the PRIMARY KEY columns first. When the key is not the first column, SQLite reads the turso file in the wrong order and cannot find rows by key.

sql
-- In turso:
CREATE TABLE t(v TEXT, k INTEGER PRIMARY KEY, w INTEGER) WITHOUT ROWID;
INSERT INTO t VALUES ('a',1,10),('b',2,20),('c',3,30);
-- Open the file in SQLite 3.53.2:
SELECT k, v, w FROM t ORDER BY k;   -- SQLite: 3|c|30  2|b|20  1|a|10  (not sorted)
SELECT v FROM t WHERE k = 2;        -- SQLite: no rows   (turso: b)

Same for PRIMARY KEY(b, a) declared after the columns. A leading TEXT PRIMARY KEY works in both directions. turso itself shows k as TEXT ('1', '2', '3'). That symptom is #6749 (affinity applied in schema order). This issue is about the file: SQLite cannot use it.

Found by writing the SQL of the FrankenSQLite test crates/fsqlite-e2e/tests/without_rowid_non_leading_pk_oracle_e2e.rs at commit d0edcc10 of Dicklesworthstone/frankensqlite with turso dc5fda12 and reading the file with SQLite 3.53.2. Permalink: https://github.com/Dicklesworthstone/frankensqlite/blob/d0edcc10f3ef59b0d62b9a277eb7c8ca57e1c2ad/crates/fsqlite-e2e/tests/without_rowid_non_leading_pk_oracle_e2e.rs#L113