SQLitePCLRaw: choosing which native SQLite your .NET app actually loads

The core assembly is deliberately provider free

SQLitePCLRaw is a .NET Portable Class Library for low-level, or raw, access to SQLite, and its package structure is the design. The main assembly is SQLitePCLRaw.core, and a portable library project would need to take a dependency on this one alone. Every other package deals with initialization and with the question of which instance of the native SQLite library is involved. That separation is the whole idea, because a provider is the piece of code that tells SQLitePCLRaw which instance of the native code to use, and more specifically a provider is an implementation of the ISQLite3Provider interface. Initialization requires a call to SQLitePCL.raw.SetProvider(), and the core package contains no providers at all. All the providers live in packages whose ids follow the pattern SQLitePCLRaw.provider.*. The result is that the choice of native SQLite is a package reference plus one line of code, not a rewrite of your data access.

Provider names are the DllImport string, which makes the mapping predictable

The naming convention exists so you can work out which library a provider will load without reading its source. The DllImport-based providers are named for the exact string used for DllImport, and the explanation given is a declaration like this.

    [DllImport("foo")]
    public static extern int whatever();

That pinvoke looks for a library called foo, which means foo.dll on Windows, libfoo.so on Unix and libfoo.dylib on macOS, with the project noting that the actual rules are more complicated than that summary. So a provider whose DllImport attributes all use foo carries foo in both its package id and its class name. There is also a dynamic provider that does not use a hard-coded DllImport string, and the project is candid that this one is the most difficult to use while supporting advanced cases where the loading decision has to be made at runtime. The included providers cover e_sqlite3 for the builds shipped with the project, sqlite3 matching the system library on iOS and the official name of builds from sqlite.org, sqlcipher for official SQLCipher builds from Zetetic, winsqlite3 for recent Windows builds, and dynamic.

Two packages, and often a third one carrying the native binary

Using SQLitePCLRaw means adding two packages, SQLitePCLRaw.core and SQLitePCLRaw.provider.whatever, and in many cases a third that contains the native SQLite library itself, for example SourceGear.sqlite3. That third package contains builds of the native SQLite code for several platforms, with the same build configuration for every platform and with full-text-search included. The distinction between the provider and the payload is worth holding onto. A provider is a bridge between the core assembly and the native code, and it does not contain the native code itself. In some cases, such as winsqlite3, that is because it does not need to, since the provider is merely a bridge to a library instance known or assumed to be somewhere else. In the case where your application bundles the library, those bits have to reach your build output somehow, and the SourceGear.sqlite3 package exists to make that convenient. The initialization call in your platform specific code names the provider class, and the word whatever differs by platform and configuration.

    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_whatever());

In the most common case, loading a library named e_sqlite3 through DllImport, the call names that provider instead.

    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_e_sqlite3());

Many different native SQLite libraries, and why the choice is yours

The reason the project has a provider layer at all is that the situation with SQLite in operating systems is not uniform. iOS ships a SQLite library that apps are allowed to use. Android also has a SQLite library, and prior to Android N, apps were allowed to use it. Recent versions of Windows have a SQLite library. On top of that, some people want to use SQLCipher as their SQLite library, and sometimes people want to compile and bundle their own custom SQLite library. SQLitePCLRaw supports all of these cases. The project describes the providers as a way of handling the fact that these cases are not equivalent in practice, and the sqlite3 provider entry makes the asymmetry explicit, since it matches the system-provided SQLite on iOS, which is fine, and on Android, which is not allowed. Choosing a provider is therefore partly a platform compliance decision and not only a technical preference, and getting it wrong on Android means the app tries to load a system library it is not permitted to use.

Encryption is a paid path no matter which provider you pick

This is the part of the project most likely to surprise you, so it is stated plainly. The maintainer no longer publishes encryption-enabled SQLite builds without cost. The recommended solution is the SQLite Encryption Extension, which is the official implementation from the SQLite team, and it is not open source, a paid licence is required. SourceGear's SQLite build service provides SEE builds in the form of NuGet packages. The recommended way to use a crypto-enabled build is to name the shared library e_sqlite3 and use the SQLitePCLRaw.config.e_sqlite3 package, which is the configuration package that pulls in the right dependencies and initialization code. That same approach also lets you use open source alternatives to SEE, and the project names two, SQLCipher with builds available for purchase from Zetetic, and SQLite3 Multiple Ciphers, maintained by a contributor and available through SourceGear's build service. So the layering stays consistent, but the key management, the licence and the build pipeline all become your problem rather than the library's.

Where the packages come from, and what the paid service adds

The distribution story has two tiers. The public NuGet package SourceGear.sqlite3 contains builds of the native SQLite code for most platforms with the most commonly used features enabled, and the project states plainly that the version available publicly is updated periodically but may not always contain the latest version of SQLite. That caveat is the kind of thing that decides your dependency policy, since a library that lags by a few SQLite releases means you are shipping a slightly older SQLite than the one upstream published. Behind that, SourceGear operates a paid service at nuget.sourcegear.com providing native SQLite builds updated immediately after each SQLite release, including regular builds or options with encryption support, and custom configurations on request. The build configuration is the same for every platform and includes full-text-search, so the public package is not a stripped-down artifact. If you need a specific SQLite version, an encryption option, or a custom configuration, you are entering a commercial arrangement with SourceGear rather than configuring the open source library yourself.

Version 3.0 changed the shape of the package set

The 3.0 release is called out as a major release with its own notes in a v3.md file at the root of the repository, and the readme points you there rather than summarising the changes, so anyone upgrading across the major version boundary has to read that file first. The release history shows the transition, with v3.0.5 published on 2026-07-27, v3.0.4 on 2026-07-19 and v2.1.12 on the same day, which looks like a 2.x maintenance release shipped alongside the 3.0 line. The repository itself is a mixed build with a Directory.Build.props, a gen_providers directory that presumably generates provider code, sn directories for strong naming, nupkgs and test_nupkgs for package output, a build directory and a version_stamp directory. The last push to the repository was on 2026-10-13, and the licence is Apache-2.0 with a LICENSE.TXT and NOTICE.TXT at the top level.

Editorial conclusion

SQLitePCLRaw fits a .NET project that needs to control exactly which native SQLite library is loaded, whether that is the system copy on iOS or Windows, a bundled build with full-text search, or an encrypted one, because the provider choice is isolated in one SetProvider call. It does not fit an application that wants a batteries-included ORM or a friendly query surface, since this layer is deliberately raw, and the encryption story ends at a paid licence either way. Before you commit, read v3.md for the 3.0 breaking changes, pick the provider that matches your platform, and check whether the publicly available SourceGear.sqlite3 build is recent enough, since the project states it is updated periodically and may lag the current SQLite release.

Frequently asked questions

Official sources

1. ericsink/SQLitePCL.raw on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases