What is the Benefit of using SQLite with Blazor WASM?

Question

I was watching this video from Steve Sanderson which demonstrates using SQLite with Blazor Web Assembly and I am contemplating using it in one of my projects. I am just trying to understand what the benefit is. It seems, from whatever information I was able to find, that the actual SQLite database resides in memory. In his project he is synchronizing it with IndexedDB for persistence. If that is the case, how is that better than storing your data as an object list in memory, and using Linq to query the objects directly, instead of Entity Framework to query from the SQLite database? You can also persist your objects to IndexedDB if that is required. I was never under the impression that it is a good idea to keep that much data in memory. My initial thought when seeing that you can use SQLite in Blazor was that it allowed you to keep data client side without keeping it all in memory. If that is not the case, what is the benefit of using SQLlite in a Blazor app?

Scrubber

Answer 1

A good rule of programming is KISS - Keep it Simple. So if the requirement of your app is satisfied by Linq to Objects, then complicating it with SQLite would seem to be the wrong thing to do.

However, in the video Steve S. does come up with requirement parameters that lend themselves to using SQLite - the application needs to process:

• lots of data
• in the client
• offline
• quickly

The use of SQLite here is not for persisting beyond client app memory.

So the answer to your question on the advantage of a Blazor app using SQLite is simply:

• If an app needs the functionality of an in-memory relational database but is trying to avoid using one, it will either be reinventing the wheel in its implementation, or missing necessary functionality.
• If an app doesn't need the functionality of an in-memory database but is using one, it will be introducing unnecessary complexity (cost).

Copenhagen

Agree with the above. I started using SQLite for testing - being able to have a SQL async context based test environment to run tests against seemed like a good idea. But the single context issue scuppered that idea, so I no longer use it. – Iambus

You listed the requirements for the Steve S application as: lots of data, in the client, offline, quickly. Would you not be able to accomplish this with objects in memory as well. I am still not grasping the advantage that SQLite is bringing to the table. – Scrubber

@Scrubber SQLite is a full RDBMS. And, yes, it can persist files in the OPFS. See the SQLite Wasm project for details. – Basilicata

Answer 2

Under the limitation of keeping the data in memory, there is no significant benefit unless you are dealing with relational data. The benefit comes when the database file/s are stored in the file system (OPFS). Then you get a full RDBMS in the browser. And, in fact, this is exactly what Google is recommending to replace the WebSQL (almost) standard.

From what I see, the downside is a pretty significant size footprint. But mostly from Entity Framework. I'm not sure if it is worth doing right now but, if you have no choice, it is good to know that such option is available. I'm pretty sure that this technology will improve significantly in the future and am looking forward to it.

I would even go as far as claiming that a footprint of several Mb of application binaries is not such a terrible deal it was just a few years ago. With 5G, caching, progressive loading (that's coming with dotnet 8), and the fact that any decent Web site has megabytes of graphics in comparison, this is most likely not a show stopper.

Basilicata