<story><title>What Happens When You Put a Database in the Browser?</title><url>https://motherduck.com/blog/olap-database-in-browser/</url></story><parent_chain><item><author>xnorswap</author><text>I don&amp;#x27;t understand these &amp;quot;DB in browser&amp;quot; products.&lt;p&gt;If the data &amp;quot;belongs&amp;quot; to the server, why not send the query to the server and run it there?&lt;p&gt;If the data &amp;quot;belongs&amp;quot; on the client, why have it in database form, particularly a &amp;quot;data-lake&amp;quot; structured db, at all?&lt;p&gt;A lot of the benefits of such databases are their ability to optimise queries for improving performance in a context where the data can&amp;#x27;t fit in memory (and possibly not even on single disks&amp;#x2F;machines), as well as additional durability and atomicity improvements. If the data is small enough to be reasonable to send to a client, then it&amp;#x27;s small enough to fit in memory, which means it&amp;#x27;ll be fast to query no matter how you go about it.&lt;p&gt;The page says one advantage is &amp;quot;Ad-hoc queries on data lakes&amp;quot;, but isn&amp;#x27;t that possible with the most basic form that simply sends a query to the database?&lt;p&gt;What am I failing to understand about this category of products?</text></item></parent_chain><comment><author>sktrdie</author><text>I think a large benefit to &amp;quot;DB in browser&amp;quot; is about the whole &amp;quot;local-first&amp;quot; software movement. A good overview is written here &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;sqlsync.dev&amp;#x2F;posts&amp;#x2F;stop-building-databases&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;sqlsync.dev&amp;#x2F;posts&amp;#x2F;stop-building-databases&amp;#x2F;&lt;/a&gt;&lt;p&gt;The essence of the approach is that a large majority of FE apps have constructed quite complex caching layers to improve performance over &amp;quot;querying backend data&amp;quot; - take a look at things like Next.js or React Query &amp;lt;- as the post above mentions, they&amp;#x27;re essentially rebuilding databases. So instead this approach just moves the db to the browser, along with a powerful syncing layer.&lt;p&gt;I think it&amp;#x27;s an approach that deserves more attention, especially to improve DX where we end up writing a whole lot of database-related logic on clients. Mind as well then just use a database on the client as well</text></comment>
<story><title>What Happens When You Put a Database in the Browser?</title><url>https://motherduck.com/blog/olap-database-in-browser/</url></story><parent_chain><item><author>xnorswap</author><text>I don&amp;#x27;t understand these &amp;quot;DB in browser&amp;quot; products.&lt;p&gt;If the data &amp;quot;belongs&amp;quot; to the server, why not send the query to the server and run it there?&lt;p&gt;If the data &amp;quot;belongs&amp;quot; on the client, why have it in database form, particularly a &amp;quot;data-lake&amp;quot; structured db, at all?&lt;p&gt;A lot of the benefits of such databases are their ability to optimise queries for improving performance in a context where the data can&amp;#x27;t fit in memory (and possibly not even on single disks&amp;#x2F;machines), as well as additional durability and atomicity improvements. If the data is small enough to be reasonable to send to a client, then it&amp;#x27;s small enough to fit in memory, which means it&amp;#x27;ll be fast to query no matter how you go about it.&lt;p&gt;The page says one advantage is &amp;quot;Ad-hoc queries on data lakes&amp;quot;, but isn&amp;#x27;t that possible with the most basic form that simply sends a query to the database?&lt;p&gt;What am I failing to understand about this category of products?</text></item></parent_chain><comment><author>jerf</author><text>To the other good points, I&amp;#x27;d add that when people start making queries that aren&amp;#x27;t O(1) or O(n), modern computers and networks are capable of reasonably conveniently moving around amounts of data where it becomes practical for remote client to use its rather substantial power to answer questions on a gigabyte or two of data with its own computing power, and if enough people are doing this at once the combined client power they can have can easily overpower any reasonable amount of cloud compute you might be willing to deploy for this problem as they run non-trivial queries. I may be happy for dozens of clients to download some data and chew through some O(n log n) with mixed O(n^2) components on their own whereas I would not care to provision enough cloud compute to handle it all.&lt;p&gt;I think people forget that as cheap as cloud compute is, client compute is even cheaper. Generally it&amp;#x27;s already paid for. (Marginal electricity costs are lost in the noise of everything else you&amp;#x27;re supporting a client user with.) And while the years of doubling every 1.5 years may be gone, clients do continue to speed up, and they are especially speeding up in ways that databases can take advantage of (more cores, more RAM, more CPU cache). Moving compute to clients can be a valuable thing in some circumstances on its own.</text></comment>