Supabase launches its .NET 8.0 SDK with dependency injection for ASP.NET Core

For teams migrating from a previous version, there are two areas of work. The first is serialization: the custom converters and [JsonProperty] attributes they used with Newtonsoft.Json need their equivalent in System.Text.Json. This change does not break the build but does alter runtime behaviour, with fields arriving empty, column names not mapping, or dates being deserialized differently. The recommendation is to cover this with integration tests against a real database before touching production.

The second area is the target of the packages. By targeting .NET Standard 2.1, the SDK leaves .NET Framework behind, which maxes out at .NET Standard 2.0. In practice, .NET Core 3.0 or higher, or .NET 5 or higher is required. If legacy services are maintained in .NET Framework, this SDK is not an option without first migrating the runtime. Supabase's documentation includes a migration guide with each breaking change and the release notes with the complete listing.

Installation is done with the command dotnet add package Supabase. This meta-package pulls in the five services (Auth, Postgrest, Storage, Realtime, and Functions). If only one is needed, it can be referenced separately, for example Supabase.Gotrue for authentication or Supabase.Postgrest for the database.

In ASP.NET Core, the recommended flow goes through the dependency injection package. The client is registered once with AddSupabase and injected wherever needed: a minimal API endpoint, a controller, or a custom service. AddSupabase registers Supabase.Client as a scoped service and also exposes each sub-client separately (IPostgrestClient, IGotrueClient, IStorageClient, IFunctionsClient, IRealtimeClient), so a class that only interacts with Storage can depend solely on that.

A critical detail that is often overlooked: a Supabase.Client builds its own HttpClient upon instantiation. If registered as scoped or transient manually, each resolution creates a new HttpClient (and a new socket), which under load exhausts the connection pool. AddSupabase resolves this by linking the client through IHttpClientFactory, so the handler is reused. To maintain consistency, any HttpClient passed through configureOptions must be replaced; proxy options, retries, and Realtime still apply.

Outside of ASP.NET Core, in console, desktop, mobile, or Unity apps, the client is built manually and initialized once with InitializeAsync. The same principle applies: one client per operation means a new HttpClient each time. Additionally, the default session handler does not store anything, so to restore a login after restarting the application, a custom SessionHandler needs to be implemented.

The basic operations follow a clear pattern. The SDK maps a table to a C# class. The model derives from BaseModel and uses attributes ([Table], [PrimaryKey], [Column]) to bind properties to columns. To read, From<T>() opens the query, Where filters, and Get executes it, returning a ModeledResponse<T> whose records are in Models. To write, Insert accepts a model or a list. For updating and deleting, there are two valid paths: if the record is already in hand, its properties are changed and Update or Delete is called.

Supabase's official documentation details each of these steps and provides examples for various integration scenarios.