Repository navigation
Managed tables - #708
Managed tables#708simolus3 wants to merge 11 commits into
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
fb4e188 to
345baec
Compare
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| By default, PowerSync stores all data as [JSON rows](/architecture/client-architecture#client-side-schema-and-sqlite-database-structure): synced rows are copied into local tables without modifications, and local updates modify an existing JSON object. This format is highly flexible and avoids schema migrations, but comes with a performance cost: | ||
|
|
||
| - Every column read forces SQLite to decode the entire JSON object, making queries slower than queries on "real" SQLite tables. In our tests, we've seen a 2x improvement for `SELECT *` queries, and a 5x improvement for aggregates, filters and ordering on columns without an index. |
There was a problem hiding this comment.
These specific multipliers (2x / 5x) aren't backed by any benchmark in the linked SDK PRs. The core-extension PR implementing this (powersync-sqlite-core#221) only benchmarked sync-apply time (writes -38.8%, reads -3.6%) and explicitly says query performance for direct tables wasn't benchmarked ("I did not benchmark direct tables for this specifically"). Either cite an actual measurement with its conditions (row/column count, index state, hardware) or describe the mechanism qualitatively instead of giving these numbers.
| By default, PowerSync stores all data as [JSON rows](/architecture/client-architecture#client-side-schema-and-sqlite-database-structure): synced rows are copied into local tables without modifications, and local updates modify an existing JSON object. This format is highly flexible and avoids schema migrations, but comes with a performance cost: | ||
|
|
||
| - Every column read forces SQLite to decode the entire JSON object, making queries slower than queries on "real" SQLite tables. In our tests, we've seen a 2x improvement for `SELECT *` queries, and a 5x improvement for aggregates, filters and ordering on columns without an index. | ||
| - JSON objects occupy more storage space than a native SQLite row, making databases slightly larger and increasing writes during large sync downloads. In our tests, direct tables decrease the file size by around 20%. |
There was a problem hiding this comment.
No benchmark for file-size reduction appears in the cited SDK PRs, and the core-extension PR (powersync-sqlite-core#221) that implements direct tables doesn't measure storage size either — only sync throughput. Replace the 20% figure with a sourced, conditioned measurement, or drop the number and describe the storage saving qualitatively.
8f4d021 to
73f0b14
Compare
I'm opening this because SDK PRs adding support for direct tables will link to the added section in the docs, so we should merge docs shortly after releasing SDKs.
This documents direct tables, which behave like raw tables except that they are created, altered and dropped automatically by the core extension. They're currently experimental, but we should otherwise recommend for users only using raw tables for performance (using raw tables for advanced SQLite features continues to be a legitimate use case for raw tables not covered by direct tables).
SDK PRs for context