Supabase lanza su SDK .NET 8.0 con inyección de dependencias

Qué cambia en el SDK .NET de Supabase con la versión 8.0.0

Supabase publicó la versión 8.0.0 de su SDK para .NET, el cliente en C# que expone Auth, base de datos, Storage, Realtime y Edge Functions detrás de una sola API. El lanzamiento viene acompañado de un paquete nuevo, Supabase.Extensions.DependencyInjection, pensado específicamente para proyectos de ASP.NET Core.

La señal para un founder técnico es directa: el backend open source que, según la compañía, ya usan más de 13 millones de desarrolladores ahora tiene una vía de entrada ordenada al ecosistema .NET, el stack donde vive buena parte del software corporativo y de las aplicaciones internas que sostienen operaciones de negocio.

Los cambios de esta versión no son cosméticos. La serialización pasó de Newtonsoft.Json a System.Text.Json, cada cliente de servicio acepta ahora un HttpClient inyectable y soporta reintentos con backoff de forma opcional, y los paquetes apuntan a .NET Standard 2.1.

¿Y esto cómo se aplica en tu negocio?

En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.

👥 Probar 7 días

Los cambios que rompen compatibilidad y cómo migrar

Si tu equipo viene de una versión mayor anterior, hay dos frentes de trabajo.

El primero es la serialización. Los convertidores personalizados y los atributos [JsonProperty] que usabas con Newtonsoft.Json necesitan su equivalente en System.Text.Json. Es el tipo de cambio que no rompe la compilación pero sí el comportamiento en tiempo de ejecución: campos que llegan vacíos, nombres de columna que no mapean, fechas que se deserializan distinto. Conviene cubrirlo con tests de integración contra una base real antes de tocar producción.

El segundo es el target de los paquetes. Al apuntar a .NET Standard 2.1, el SDK deja atrás .NET Framework, que llega como máximo a .NET Standard 2.0. En la práctica necesitas .NET Core 3.0 o superior, o .NET 5 o superior. Si mantienes servicios legacy en .NET Framework, este SDK no es una opción para ellos sin migrar el runtime primero.

La documentación de Supabase incluye una guía de migración con cada cambio de ruptura y las notas de la release con el listado completo.

Cómo se configura el cliente (y el error que hunde tu API en producción)

La instalación es un comando: dotnet add package Supabase. Ese meta-paquete arrastra los cinco servicios (Auth, Postgrest, Storage, Realtime y Functions). Si solo necesitas uno, puedes referenciarlo por separado, por ejemplo Supabase.Gotrue para autenticación o Supabase.Postgrest para la base de datos.

En ASP.NET Core el flujo recomendado pasa por el paquete de inyección de dependencias. Registras el cliente una vez con AddSupabase y lo inyectas donde lo necesites: un endpoint minimal API, un controlador o tu propio servicio. AddSupabase registra Supabase.Client como servicio scoped y también expone cada sub-cliente por separado (IPostgrestClient, IGotrueClient, IStorageClient, IFunctionsClient, IRealtimeClient), así una clase que solo toca Storage puede depender únicamente de eso.

Aquí está el detalle que más importa y el que más se pasa por alto: un Supabase.Client construye su propio HttpClient al instanciarse. Si lo registras como scoped o transient a mano, cada resolución crea un HttpClient nuevo —y un socket nuevo—, lo que bajo carga agota el pool de conexiones. AddSupabase resuelve esto enlazando el cliente a través de IHttpClientFactory, de modo que el handler se reutiliza. Para mantener la coherencia, reemplaza cualquier HttpClient que pases por configureOptions; tus opciones de proxy, reintentos y Realtime siguen aplicándose.

Fuera de ASP.NET Core —apps de consola, escritorio, móvil o Unity— construyes el cliente tú mismo y lo inicializas una sola vez con InitializeAsync. El mismo principio aplica: un cliente por operación significa un HttpClient nuevo cada vez. Además, el manejador de sesión por defecto no guarda nada, así que si quieres restaurar un inicio de sesión tras reiniciar la app necesitas implementar tu propio SessionHandler.

Las operaciones básicas: consultas, escritura, auth y storage

El SDK mapea una tabla a una clase de C#. Tu modelo deriva de BaseModel y usa atributos ([Table], [PrimaryKey], [Column]) para vincular propiedades con columnas.

Para leer, From<T>() abre la consulta, Where filtra y Get la ejecuta devolviendo un ModeledResponse<T> cuyos registros están en Models. Para escribir, Insert acepta un modelo o una lista. Para actualizar y borrar hay dos caminos válidos: si ya tienes el registro en mano, cambias sus propiedades y llamas a Update o Delete sobre el modelo; si no lo tienes, el query builder te ahorra el Get con Set(...).Where(...).Update().

Un aviso que evita dolores de cabeza: aunque la sintaxis recuerda a Entity Framework, el comportamiento no es el mismo. No hay DbContext, ni change tracker, ni SaveChanges. Cambiar una propiedad no hace nada hasta que llamas a Update, y cada llamada es su propia petición HTTP. Si vienes de EF, ese cambio mental es el que más bugs silenciosos genera.

La autenticación vive en supabase.Auth, con SignUp y SignIn por email y contraseña, y la misma superficie cubre OAuth, magic links, teléfono y SSO. Con AutoRefreshToken activado, el cliente renueva el token antes de que expire y lo adjunta a las llamadas de base de datos y Storage, de modo que Row Level Security se aplica al usuario autenticado. Storage funciona igual de simple: supabase.Storage.From("avatars").Upload(...).

Sobre las claves, la versión 8.0.0 sumó las nuevas publishable y secret junto a las ya conocidas anon y service. La regla no cambia: publishable o anon en todo lo que se distribuye al usuario, secret y service solo en el servidor. Una service key omite Row Level Security, así que no tiene lugar en una app cliente; cuando necesitas ese nivel de acceso, usa un cliente separado.

¿Por qué Supabase empuja el SDK .NET justo ahora?

El contexto de negocio ayuda a leer el movimiento. Según el comunicado difundido por PR Newswire, Supabase anunció US$150 millones en financiación nueva liderada por GIC, con participación de CapitalG (el fondo de crecimiento de Alphabet), IronArc y SquarePeg, apenas cuatro meses después de una Serie F de US$500 millones. En la misma operación anunció la adquisición de Turso, una plataforma orientada a aprovisionar grandes volúmenes de bases de datos para cargas de trabajo de agentes.

Los números que acompañan ese anuncio explican la urgencia: la compañía dice sumar más de 1 millón de usuarios y 4 millones de bases de datos por mes, con cerca del 70% de las bases nuevas creadas por agentes o herramientas de IA. Eso sigue a un aumento interanual del 600% en bases de datos reportado en junio. Fundada en 2020, Supabase afirma tener más de 13 millones de desarrolladores y un marketplace de más de 100 herramientas integradas.

Paul Copplestone, cofundador y CEO, lo resumió así en el comunicado: "El futuro son los agentes y la arquitectura que aporta Turso nos ayudará a acelerar Supabase como la plataforma de backend que soporte ese futuro". Un resumen publicado en note.com que cita a CNBC situó la valoración de la compañía en US$10.500 millones en junio de 2026.

En ese marco, un SDK maduro para .NET no es un detalle menor: es la puerta de entrada a las empresas que construyen software interno en C# y que hasta ahora tenían que resolver la integración a mano.

¿Qué significa esto para tu startup?

Tres cosas concretas, según el stack que tengas.

  • Si ya usas Supabase desde .NET, planifica la migración a la 8.0.0 con tests. El cambio a System.Text.Json es el punto de mayor riesgo: revisa cada atributo [JsonProperty] y cada convertidor personalizado antes de desplegar. Y si tu proyecto corre sobre .NET Framework, verifica primero el runtime, porque el SDK ya no lo soporta.
  • Si estás montando un backend nuevo en ASP.NET Core, usa el paquete de inyección de dependencias en lugar de instanciar el cliente a mano. Registrar el cliente como scoped o transient sin IHttpClientFactory agota el pool de conexiones bajo carga. Es un error que no aparece en desarrollo y sí en el primer pico de tráfico.
  • Audita tus claves y tu Row Level Security hoy, no después. Un análisis recopilado por note.com señaló en septiembre de 2026 que 1 de cada 18 aplicaciones construidas con IA dejó sus bases de datos abiertas, con 16.326 exposiciones registradas en Supabase. Con la service key fuera del cliente y RLS activado y probado, ese riesgo se cierra.

El SDK .NET de Supabase no cambia el mercado por sí solo, pero sí baja la fricción para un perfil de equipo que hasta ahora miraba el ecosistema desde afuera. Si tu producto vive en C#, la barrera técnica para probarlo acaba de desaparecer.

Fuentes

¿Y esto cómo se aplica en tu negocio?

En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.

👥 Probar 7 días

Daily Shot: Tu ventaja táctica

Lo que pasó en las últimas 24 horas, resumido para que tú no tengas que filtrarlo.

Suscríbete para recibir cada mañana la curaduría definitiva del ecosistema startup e inversionista. Sin ruido ni rodeos, solo la información estratégica que necesitas para avanzar:

  • Venture Capital & Inversiones: Rondas, fondos y movimientos de capital.
  • IA & Tecnología: Tendencias, Web3 y herramientas de automatización.
  • Modelos de Negocio: Actualidad en SaaS, Fintech y Cripto.
  • Propósito: Erradicar el estancamiento informativo dándote claridad desde tu primer café.

📡 El Daily Shot Startupero

Noticias del ecosistema startup en 2 minutos. Gratis, todos los días.

Share to...