Now is a great time to build web apps just like people built native apps in the early 2000s, and by that I mean:

Using a fully-stocked local SQLite database for state management instead of coupling a sketchy heap of local data with a separate remote API.

The WebAssembly SQLite Renaissance

SQLite’s billions and billions of deployments show that it works. It’s rather strange that almost none of them are on the web.

Lucky for us, smart people like @rhashimoto and @phiresky are working on making sqlite really shine on the web, in all kinds of interesting ways:

• wa-sqlite is a newer SQLite+WASM project with an experimental IndexedDB VFS for excellent performance and transactional reliability.

• An HTTP VFS for SQL.js that allows you to query reads from remote multi-gigabyte sqlite database files hosted on S3 or R2 for cheap by fetching pages intelligently and efficiently.

Problem: There still is no persistent storage on the web

Writing to IndexedDB is all good and well, but the reality is that browsers like Safari act like Swabian apartment-dwellers, strictly observing the Kehrwoche, periodically deleting locally stored data for privacy reasons.

This is a problem!

People really expect their data to still be there the next morning, or a month later. Nothing should be deleted unless instructed. Ever.

Solution: Sync local sqlite pages to a durable remote copy

There is no other way. We will never get persistent storage in the browser. Don’t @ me, or I will @ you back 2 years later.

Luckily, building this isn’t that hard to imagine:

• Straight up call S3/DynamoDB API methods to store and retrieve pages. Hello range requests. Remote API: Done.

• If data is gone on startup, stream in from remote.

• On write transactions, copy pages to remote, or even block until done.

I’ll continue this post with an implementation and write-up in a future post.