When to use Microsoft.Data.Sqlite over sqlite-net-pcl?

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.

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"