<story><title>Accidental database programming</title><url>https://sqlsync.dev/posts/stop-building-databases/</url></story><parent_chain><item><author>giancarlostoro</author><text>Genuinely curious why not just cache the relevant bits in LocalStorage &amp;#x2F; SessionStorage? I seem to remember Chrome trying to add a literal SQL database to the browser, but it never panned out, localStorage became king. I don&amp;#x27;t mean to downplay the usefulness, just I usually opt for what the browser gives me. I&amp;#x27;m huge on WASM and what it will do for the browser as it matures more (or grows in features).</text></item><item><author>neilk</author><text>I’m familiar with this project - the creator is a friend. I’ll try to get him on here to answer questions.&lt;p&gt;He’s a seasoned database architect. With SQLsync he’s made a way for frontend developers to query and update a remote database as if it was completely located right in the browser. Because it basically is. The power of WASM makes it possible to ship a whole SQLite database to the browser. The magic is in how it syncs from multiple clients with a clever but simple reactive algorithm.&lt;p&gt;It’s a radical attack on the whole problem. Much of our work as developers is about syncing data. When you start looking at React and REST APIs as a kind of sync procedure, this approach can open a lot of new possibilities. You don’t have to write a weird bespoke database of trees of objects fetched and cached from the API any more. You can just update and query it locally, with all the power of a relational database.</text></item></parent_chain><comment><author>carlsverre</author><text>Good question.&lt;p&gt;First to address the main point: why not cache the relevant bits in some kind of local storage. SQLSync plans on doing this, specifically using OPFS for performance (but will have fallbacks to localstorage if needed).&lt;p&gt;Second to address the question of why not use built in kv stores or browser side databases. One answer is another question: how do you solve sync?&lt;p&gt;One approach is using a data model that encodes conflict handling directly, like CRDTs. This approach is easier to put into general kv stores, as syncing requires simply exchanging messages in any order. I find this solution is well suited to unstructured collaboration like text editing, but makes it harder to coordinate centralised changes to the data. Centralised changes are nice when you start introducing authentication, compaction, and upgrades.&lt;p&gt;Another approach is doing something similar to how Git Rebase works. The idea is to let the application state and server state diverge, and then provide an efficient means for the app to periodically reset to the latest server state and replay any unacked mutations. This approach requires the ability to re-run mutations efficiently as well as efficiently track multiple diverging versions of the database state. It&amp;#x27;s certainly possible to build this model on top of local storage.&lt;p&gt;For SQLSync, I found that by controlling the entirety of SQLite and the underlying storage layer I was able to create a solution that works across platforms and offers a fairly consistent performance profile. The same solution runs in native apps, browser sessions (main thread or workers), and on serverless platforms. One of my goals is to follow the lead of SQLite and keep my solution fairly agnostic to the platform (while providing the requisite hooks for things like durable storage).</text></comment>
<story><title>Accidental database programming</title><url>https://sqlsync.dev/posts/stop-building-databases/</url></story><parent_chain><item><author>giancarlostoro</author><text>Genuinely curious why not just cache the relevant bits in LocalStorage &amp;#x2F; SessionStorage? I seem to remember Chrome trying to add a literal SQL database to the browser, but it never panned out, localStorage became king. I don&amp;#x27;t mean to downplay the usefulness, just I usually opt for what the browser gives me. I&amp;#x27;m huge on WASM and what it will do for the browser as it matures more (or grows in features).</text></item><item><author>neilk</author><text>I’m familiar with this project - the creator is a friend. I’ll try to get him on here to answer questions.&lt;p&gt;He’s a seasoned database architect. With SQLsync he’s made a way for frontend developers to query and update a remote database as if it was completely located right in the browser. Because it basically is. The power of WASM makes it possible to ship a whole SQLite database to the browser. The magic is in how it syncs from multiple clients with a clever but simple reactive algorithm.&lt;p&gt;It’s a radical attack on the whole problem. Much of our work as developers is about syncing data. When you start looking at React and REST APIs as a kind of sync procedure, this approach can open a lot of new possibilities. You don’t have to write a weird bespoke database of trees of objects fetched and cached from the API any more. You can just update and query it locally, with all the power of a relational database.</text></item></parent_chain><comment><author>justincormack</author><text>There is a literal SQL store in the browser its the sqlite Wasm port. Its just panning out a little differently.</text></comment>