Sync engine for keeping backend databases in sync with in-app SQLite.
Postgres | MongoDB | MySQL | SQL Server
🐘🌿🐬🛢️«-» 🪶
PowerSync
Loading...
In plain English: NORMAL/OFF = faster but may lose latest writes; FULL/EXTRA = safer but slower.
It does this by not insisting every commit hit the disk immediately. Instead of updating the main database file right away, it writes changes into side log files first. That is cheaper, so small write transactions finish much faster.
So the tradeoff is simple: faster writes now, weaker crash protection for newest data. This is often fine for local-first apps where recent changes can be retried, re-synced, or recreated from server state.
The new OPFSWriteAheadVFS for wa-sqlite not only brings concurrent reads to SQLite on the web, but also makes write transactions faster!
We're at @stirtrek!
Come say hi, grab a free tshirt, enter a giveaway for a Meta Quest 3S, and chat about building fullstack AI applications
In default mode, commit means "this transaction is recorded in WAL and the database stays valid," not "the browser has definitely flushed this to storage." If the tab crashes or the device loses power, the app may lose the most recent writes, but the database should not come back corrupted.
Key idea: keep the database correct even if newest writes are not fully durable yet.
Full discussion - github.com/rhashimoto/...
If the app needs stronger guarantees, it can turn durability back up with PRAGMA synchronous=FULL or EXTRA. Then the VFS flushes more aggressively so recent commits are much more likely to survive crashes, but write performance drops.
Why the speedup is big: forcing storage flush on every tiny write is expensive. That flush is often the slowest part of the commit. By skipping it on a hot path, the VFS removes a lot of overhead, which especially helps with workloads with many small transactions.
