Performance Optimization - using Count's local DuckDB database

So using counts. Db database alongside your own is a really powerful way to unlock the freedom to do extensive analysis on your data without worrying about the query load going back to your database. And there are several ways to make use of this account. So we have dot DB in the browser, and this is where we switch database cells over to local cells that make use of memory in the browser. The benefit of this is that they run really fast in the canvas, but the one limitation is that the memory limit is just over one hundred and twenty megabytes. Usually, there's some aggregation needed within your database cells to get your data into smaller chunks before you can then switch over to using local cells. Next is DuctDB on the server. This works in a similar way, but the memory limit is vastly increased. So you can hold up thirty two gigabytes in counts local dot DB database on the server. The exact limit depends on the plan that you were on, but this means that you can have less initial database sales and switch over to local sales much sooner. And finally, we have dot DB in count metrics. This is our semantic layer, and caching for this is available at a workspace level. So you will notice that dot DB in the browser and the server works, within individual canvases where you need to start with at least one database cell to then switch over. But with our semantic layer, we cache at a workspace level, and then multiple canvases can make use of this. So this can massively decrease your database query load. So I'll demonstrate how to make use of dot d b in the browser. Here I have a number of cells all going back to my database. We're creating two different tables here. I'm then joining them and then doing subsequent analysis and a visual. So if I keep the two database cells that are looking at my tables, I can highlight the remainder, and then I can come over to the source drop down, and I can just switch this to local dot t b. So now everything downstream of these two database cells are being run within counts local database and not going back to your your own database. I will also demonstrate how to make use of Dutdb on the server. So as I mentioned, the memory limit for this is vastly higher than Dutdb in the browser. Just to demonstrate what this looks like, we have a database cell here, and I am limiting the query to a hundred thousand rows. By default, we limit the number that come into the browser to ten thousand. And then we have this little message in the corner that says that rows are limited, and we've only retrieved the first ten thousand rows. This means when I have subsequently added a local dot DB cell that we have a warning here. Dot DB in the browser only works if you have managed to download everything initially into the browser. What we can do is if we go back to our parent database cell, we now have the option in the design bar to change this limit from ten thousand to unlimited. We specify a browser download limit, which by default here is ten thousand. And now we can see that this has changed down here. We are now showing ten thousand of one hundred thousand rows. When I click on this message, we see confirmation that all one hundred thousand rows have been extracted from your database into account servers. So now when I look at my local dot DB cell, we no longer have that warning, and we are using that increased memory allowance in the server to do our analysis.