<story><title>Why SQLite is so great for the edge</title><url>https://blog.turso.tech/why-sqlite-is-so-great-for-the-edge-ee00a3a9a55f</url></story><parent_chain></parent_chain><comment><author>jgrahamc</author><text>This no need to compile SQLite into your Cloudflare Worker. We provide it native on our platform as D1. And it gives you replication. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;d1-turning-it-up-to-11&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;d1-turning-it-up-to-11&amp;#x2F;&lt;/a&gt;&lt;p&gt;Also, I think the idea of “edge” doesn’t make a ton of sense. What we really need is code and data that move around as needed for the best performance. See: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-workers-smart-placement&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-workers-smart-placeme...&lt;/a&gt;&lt;p&gt;What people call “edge” is a single optimization bringing code near the user. I think we should go far beyond that. Sure, use something like Cloudflare Workers for your “edge” needs (ie bringing your React app close to the end user&amp;#x2F;doing server side rendering). But don’t stop there because where data resides, what APIs you call are all going to matter.&lt;p&gt;That&amp;#x27;s the vision of something I called the &amp;quot;Supercloud&amp;quot;: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;welcome-to-the-supercloud-and-developer-week-2022&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;welcome-to-the-supercloud-and-de...&lt;/a&gt;</text></comment>
<story><title>Why SQLite is so great for the edge</title><url>https://blog.turso.tech/why-sqlite-is-so-great-for-the-edge-ee00a3a9a55f</url></story><parent_chain></parent_chain><comment><author>samwillis</author><text>For a tenanted SAAS app SQLite at the edge is a really compelling architecture. You have a single DB per customer&amp;#x2F;company&amp;#x2F;group with all their users woking against that. It can operate at the edge, closest to where the majority of the customers users are.&lt;p&gt;SQLite could scale to even quite large customers with this.&lt;p&gt;Another really compelling architecture is a DB per user, with partial&amp;#x2F;selective sync between the nodes. If you then couple this with a &amp;quot;local first&amp;quot; design, the &amp;quot;edge&amp;quot; just becomes an other local deployment that the users db can sync against. Collaborative apps, where the users have their own documents but can also share&amp;#x2F;fork them would align well with this.&lt;p&gt;I believe starting with &amp;quot;local first&amp;quot; and using the edge for sync and &amp;quot;online only&amp;quot; modes is going to become the default for a significant number of apps moving forward. SQLite with CRDT based syncing and merge conflict resolution is the way to do this. There are a couple of exciting projects working on this:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;electric-sql.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;electric-sql.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;vlcn.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;vlcn.io&amp;#x2F;&lt;/a&gt;</text></comment>