serverless vs sync-wasm For Web Apps

[mcmah309]

Is serverless or sync-wasm better for web apps?

I would guess the answer comes down to the size of serverless vs sync-wasm package and the amount of data you are sending over the wire.

• serverless: Does not cache locally
• sync-wasm: Stores the data locally synced from the server

Assuming using sync-wasm with "partial sync" the amount of unnecessary data sent over the wire can be reduced or be the exact same as serverless? If so, the formula for a read heavy app would be:

• serverless: size of package + number of expected requests * size of expected requests
• sync-wasm: size of package + size of expected requests

Inspecting the npm packages serverless is the smaller package of the two, ~93KB while sync-wasm's main.es.js is ~13MB (both not minified). This should also be considered from an initial load time of the application perspective.

I am also assuming with "partial sync" the db.sync() function does not download any changes, but rather updates a tracker of what data is fresh on the client and what it does not have so any subsequent queries can fetch from the server if need be? If in "partial sync" mode, it still syncs the whole database on db.sync() rather than tracking what is fresh and what is not, this greatly changes the formula, since it would remove the use case of partial sync over sync here. The formula would change to:

• sync-wasm: size of package + size of user db (Since subsequent request need to make sure data is up-to-date and will call db.sync() before).

Is my reasoning sound? Any additional considerations to add?

[cookesan]

Your model is directionally right, but partial sync is not just a freshness tracker.

The sync-wasm package is the local database path: it brings pages into browser storage and syncs with Turso Cloud. The current partial-sync option is experimental and is configured around bootstrap strategies such as "load the first N bytes" or "load pages touched by this SQL query", plus segment/prefetch options. That reduces how much of the database is materialized locally, but it still has the WASM/local-storage cost and page-level sync behavior.

So I would choose this way:

• @tursodatabase/serverless for normal web apps where first load size and simple remote reads matter most
• @tursodatabase/sync-wasm when offline/local-latency reads are worth the larger WASM startup and local database state
• partial sync when the local-database model is valuable but only a subset of pages should be pulled up front

For a read-heavy app, the missing term in the formula is repeated reads. Serverless keeps paying network latency per remote query; sync-wasm pays a bigger initial/runtime cost so later reads can hit local state when the needed pages are present.

[mcmah309]

The current partial-sync option is experimental and is configured around bootstrap strategies such as "load the first N bytes" or "load pages touched by this SQL query", plus segment/prefetch options.

and from the docs

Both modes continue to lazily fetch missing pages on demand.

The part that is ambiguous to me is how this lazy fetching is done. Is it done automatically or does the programmer need to do push/pull like regular sync. If push/pull is needed, does pull:

• Fetch all the updates to the current pages/bytes that have been loaded

Or

• Mark pages/bytes as stale (freshness) if they have changed, so any subsequent queries on these pages are re-fetched from the server lazily at query time

Or something else

[OrthelT]

According to the docs, when using partial sync:

Reads on not-yet-downloaded data transparently trigger on-demand page fetches.

Writes are still synced upstream with .push()