Even though the documentation uses sqlite-net-pcl while points to Microsoft.Data.Sqlite as an alternative, it is not clear when or why use one over another.

This article uses the sqlite-net-pcl NuGet package to provide SQLite database access to a table to store todo items. An alternative is to use the Microsoft.Data.Sqlite NuGet package, which is a lightweight ADO.NET provider for SQLite. Microsoft.Data.Sqlite implements the common ADO.NET abstractions for functionality such as connections, commands, and data readers.

What triggered me to ask this question is that the optional Maui project sample that ships with the .NET 9.0 framework uses Microsoft.Data.Sqlite instead.

Even though the documentation uses sqlite-net-pcl while points to Microsoft.Data.Sqlite as an alternative, it is not clear when or why use one over another.

This article uses the sqlite-net-pcl NuGet package to provide SQLite database access to a table to store todo items. An alternative is to use the Microsoft.Data.Sqlite NuGet package, which is a lightweight ADO.NET provider for SQLite. Microsoft.Data.Sqlite implements the common ADO.NET abstractions for functionality such as connections, commands, and data readers.

What triggered me to ask this question is that the optional Maui project sample that ships with the .NET 9.0 framework uses Microsoft.Data.Sqlite instead.

• sqlite
• maui
• -9.0
• sqlite-net-pcl
• microsoft.data.sqlite

• This question is similar to: Difference between System.Data.SQLite and sqlite-net-pcl. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. – tommat208 Commented Mar 19 at 13:02
• 1 if you prefer (or need) ADO.NET abstractions, use MS package. If you prefer the ORM provided by sql-net-pcl, use that. Use of EF (I think) would also require the MS package – Jason Commented Mar 19 at 14:47

1 Answer 1

Not a fully fledge answer but as stated in this discussion @github:

The external lib was recommended for historical reasons, because there were no alternatives originally. But that's no longer the case - Microsoft.Data.Sqlite now has support.

So provided Microsoft.Data.Sqlite has decent performance we'll be switching to recommending it. However, it'll take a while for investigations to conclude.

The original poster also claims that

sqlite-net-pcl is still missing some System.Data.Sqlite features like transactions or datareaders.

While as far as I can see that the package supports transaction per se (via it's own abstraction - RunInTransaction(Async)) it seems that it does not support the "idiomatic" way to do them.

So the question is basically is down to how reusable is your code. Using Microsoft.Data.Sqlite should make it more integrated with other framework-provided products and easier use stuff like EF Core and others if needed.

Also I would recommend to benchmark your concrete case - maybe one of the packages will have noticable performance gain in the critical path, though I doubt that.

P.S.

There is a claim that "using sqlite-net-pcl is a lot easier"