Supabase Edge Functions Deno: review 2026

Las Supabase Edge Functions con Deno son funciones TypeScript distribuidas globalmente que corren sin build chain ni bundler, con cold starts de 42ms promedio en 2026 (contra 870ms de mayo 2025) y 500.000 invocaciones gratis por mes incluidas en el plan gratuito.

Cloudflare es una plataforma de infraestructura web y red de distribución de contenidos (CDN) desarrollada por Cloudflare Inc., que proporciona servicios de protección DDoS, caching, DNS, y edge computing para acelerar y asegurar sitios web y aplicaciones.

Qué son Supabase Edge Functions y por qué importan en 2026

Supabase Edge Functions es el sistema de funciones serverless de Supabase: código TypeScript que corre en el runtime Deno, distribuido en más de 35 regiones globales, ejecutándose cerca del usuario final en vez de en un servidor centralizado. No hay que confundirlas con las Database Functions (que son PL/pgSQL y viven dentro de Postgres): las Edge Functions son para lógica de aplicación, webhooks, endpoints de API y procesamiento que requiere runtime externo a la base de datos.

El diferenciador real no es la distribución geográfica (eso también lo tienen los competidores). Es el modelo de desarrollo: un archivo TypeScript, sin configuración adicional, que importa dependencias directamente por URL y se despliega en segundos.

El runtime Deno: TypeScript sin build chain ni bundler

La decisión arquitectónica más importante de Supabase Edge Functions es usar Deno, y tomó tiempo entender por qué importa tanto. Cuando un desarrollador publicó su revisión en mayo de 2026 después de cinco meses en producción (desde diciembre 2025) con 13 funciones desplegadas, el punto que más resaltó fue la ausencia de fricción en el workflow.

Con Supabase Edge Functions: creás un archivo .ts, escribís el handler, ejecutás supabase functions deploy. Eso es todo. Sin package.json, sin configuración de esbuild, sin tsconfig.json, sin serverless.yml.

Comparado con los flujos alternativos, la diferencia es concreta. Para el mismo webhook de Stripe en Cloudflare Workers, el workflow requirió instalar un archivo de configuración, escribir el handler en module syntax que esbuild pudiera bundlear, y gestionar un paso de build separado que producía el output final. Con AWS Lambda y el Serverless Framework, sumale la configuración de IAM roles y el deployment package. Con Supabase, escribís la función y la desplegás. No hay intermedio. Cubrimos ese tema en detalle en herramientas para automatizar deployments.

Deno 2.1, que Supabase incorporó en 2026, trajo compatibilidad completa con npm, por lo que ahora podés importar paquetes npm convencionales además de las importaciones por URL nativas de Deno. Eso resolvió uno de los frenos que tenía el ecosistema.

Cold starts y performance: la mejora del 97% que cambió el juego

Ponele que tenés una función de autenticación que se activa con poca frecuencia. Con los tiempos viejos de Edge Functions, el primer request después de un período de inactividad podía tardar casi un segundo. Para una experiencia de login, eso es catastrófico.

Según el blog oficial de Supabase, el storage persistente implementado en Q2 2026 redujo los cold starts de 870ms promedio a 42ms, una mejora del 97%. Para comparar: AWS Lambda oscila entre 500ms y 2000ms según el runtime y el tamaño del deployment package.

42ms es un número que cambia las decisiones de arquitectura. Funciones que antes tenías que mantener “calientes” con pings artificiales ahora pueden dormir sin problema.

Casos de uso reales en producción: webhooks, API y más

El developer que revisó el sistema en mayo de 2026 desplegó 13 funciones distintas durante cinco meses de uso en producción real (desde diciembre 2025), junto a Cloudflare Workers y AWS Lambda sirviendo la misma aplicación. Ese contexto comparativo es valioso porque no es marketing, es experiencia directa.

Los casos que cubrió incluyen: un webhook handler para pagos con Stripe (la primera función desplegada, en enero de 2026), callbacks de autenticación, triggers de procesamiento de archivos (filtros de imagen), endpoints de API para una app móvil, y un trabajo programado de limpieza de datos. Un rango amplio que muestra que Edge Functions no se limitan a una sola función para webhooks. Ya lo cubrimos antes en optimización SEO en plataformas globales.

El free tier de 500.000 invocaciones por mes (confirmado en la documentación oficial) hace que cualquiera de estos casos sea accesible sin pagar nada hasta escalar a volumen serio. Para proyectos en etapa de validación o equipos pequeños, eso no es menor.

Seguridad, Row Level Security y validación en Edge Functions

Acá viene lo bueno, o mejor dicho, la parte que te puede quemar si no la leés con cuidado.

Las Edge Functions usan la Service Role Key de Supabase. Eso significa que operan con privilegios elevados y no respetan Row Level Security automáticamente. Si tu lógica de RLS depende de auth.uid(), en el contexto de una Edge Function ese valor retorna NULL.

¿Qué implica esto en la práctica? Que si insertás un registro desde una Edge Function sin validar explícitamente la identidad del usuario, podés estar insertando datos sin las restricciones que creías tener. La seguridad no es automática: tenés que implementar los checks vos mismo dentro de la función, validando contra el sistema de autenticación de Supabase antes de operar sobre la base de datos.

La diferencia con el cliente de JavaScript del navegador (que sí respeta RLS porque opera con el token del usuario) es fundamental. Diseñar pensando que el comportamiento es el mismo es el error más común.

Manejo de webhooks: el patrón Stripe validado en producción

El caso de webhook de Stripe es el que más aparece en la documentación y en la experiencia de usuarios reales, con razón: es el escenario donde Edge Functions brillan más claramente. Te puede servir nuestra cobertura de aceleración de tiendas desde el edge.

El flujo según la documentación oficial de Supabase es este:

• Configurar la función con auth: 'none' para que Stripe pueda llamarla sin autenticación de Supabase.
• Leer el body raw del request (Stripe requiere el body sin parsear para verificar la firma).
• Verificar la firma del webhook usando el secreto compartido con Stripe.webhooks.constructEvent().
• Solo después de verificar, operar contra la base de datos con los privilegios del Service Role.

Lo interesante es que este patrón aplica a cualquier webhook externo, no solo Stripe. GitHub webhooks, Mercado Pago, cualquier servicio que mande eventos HTTP con firma verificable. La función valida primero, actúa después. Ese orden es el que separa una implementación correcta de una vulnerable.

Supabase Edge Functions vs Cloudflare Workers vs AWS Lambda

Si ya usás Supabase para la base de datos, la comparación tiene contexto diferente al que se hace entre herramientas independientes. El factor integración cambia el análisis.

Criterio	Supabase Edge Functions	Cloudflare Workers	AWS Lambda
Cold start promedio (2026)	42ms	~5ms	500-2000ms
Integración con Postgres/Auth	Nativa, sin config	Requiere conexión externa	Requiere conexión externa
Build step requerido	No	Sí (esbuild/wrangler)	Sí (package + deploy)
Free tier	500K invocaciones/mes	100K requests/día	1M requests/mes
Runtime	Deno (TypeScript nativo)	V8 isolates	Node.js, Python, otros
Distribución global	35+ regiones	300+ ubicaciones	Regiones seleccionadas

Cloudflare Workers tiene cold starts más rápidos (los V8 isolates arrancan en milisegundos). Si la latencia mínima absoluta es el único criterio, Workers gana. Eso sí: si tu backend es Supabase, usar Workers para la lógica de aplicación significa gestionar conexiones externas a Postgres, manejar autenticación por separado y renunciar a la integración directa. El patrón más común que aparece en la comunidad en 2026 es frontend en Cloudflare Pages, lógica de borde en Edge Functions de Supabase, y base de datos en Postgres de Supabase. Todo junto.

Para proyectos que ya están en Supabase, migrar lógica a Lambda o Workers solo para ganar unos milisegundos en cold start raramente tiene sentido. El overhead de gestión supera la ganancia.

Errores comunes al implementar Edge Functions

Asumir que RLS cubre las operaciones de la función

Ya lo mencionamos, pero vale repetirlo porque es el error con más consecuencias: la Service Role Key bypasea RLS. Si tu modelo de seguridad asume que las políticas de fila van a filtrar datos en Edge Functions igual que en el cliente, estás expuesto. Implementá validación de identidad explícita dentro de cada función que opere datos sensibles. Complementá con plataformas edge para construcción web.

Parsear el body antes de verificar la firma del webhook

Stripe y otros servicios de webhooks necesitan el body como buffer raw para verificar la firma HMAC. Si hacés await req.json() antes de construir el evento verificado, la firma falla. Parece obvio cuando lo leés, pero es el error que aparece en el 80% de los issues de webhooks de Stripe en los foros de Supabase.

Olvidar configurar CORS para endpoints de API pública

Si una Edge Function va a ser llamada desde un browser, necesitás manejar la preflight request OPTIONS y devolver los headers CORS correctos. Las Edge Functions no los configuran automáticamente. Una función que funciona perfectamente en Postman y falla misteriosamente desde el frontend generalmente tiene este problema.

No usar variables de entorno para secretos

Meter claves de API directamente en el código de la función (porque “es más fácil para probar”) es el camino más corto al incidente de seguridad. Supabase tiene soporte para secrets con supabase secrets set. Usalos desde el principio, no como refactor posterior.

Preguntas Frecuentes

¿Cómo funcionan las Edge Functions de Supabase con Deno?

Son funciones TypeScript que corren en el runtime Deno, distribuidas en más de 35 regiones globales. Cada función es un archivo .ts que exporta un handler; se despliegan con supabase functions deploy sin build step, sin bundler y sin configuración adicional. Deno maneja las dependencias por URL o, desde Deno 2.1, también desde npm.

¿Cuánto tardan los cold starts en Supabase Edge Functions en 2026?

El promedio actual es de 42ms, una reducción del 97% respecto a los 870ms que tenían antes de la implementación del storage persistente en Q2 2026. Para comparar, AWS Lambda típicamente tiene cold starts entre 500ms y 2000ms según el runtime. El storage persistente fue la actualización que hizo la diferencia en la experiencia de producción.

¿Supabase Edge Functions o Cloudflare Workers: cuál es mejor?

Depende del stack. Si ya usás Supabase para base de datos y autenticación, las Edge Functions tienen integración nativa que Workers no puede replicar sin configuración adicional. Cloudflare Workers tiene cold starts más bajos (~5ms) y mayor distribución geográfica. El patrón más común en 2026 es usar ambas: Cloudflare para assets estáticos y Supabase Edge Functions para lógica que necesita tocar la base de datos o el sistema de auth.

¿Cómo manejar webhooks de Stripe con Supabase Edge Functions?

Configurar la función con auth: 'none', leer el body como buffer raw antes de cualquier parseo, y verificar la firma con el secreto del webhook antes de operar contra la base de datos. Este orden es crítico: parsear el body antes de verificar la firma hace que la verificación falle. La documentación oficial de Supabase tiene el ejemplo completo.

¿Las Edge Functions de Supabase respetan el Row Level Security de Postgres?

No automáticamente. Las Edge Functions usan la Service Role Key, que bypasea RLS. La función auth.uid() retorna NULL en ese contexto. Para operar con las restricciones de RLS, tenés que validar la identidad del usuario explícitamente dentro de la función y pasar el JWT correspondiente al cliente de Supabase. Si no lo hacés, las políticas de fila no aplican.

Conclusión

Supabase Edge Functions Deno resolvió en 2026 los dos problemas que las hacían difíciles de adoptar: la fricción del workflow (eliminada con el modelo de archivo único sin build chain) y los cold starts (reducidos de 870ms a 42ms con el storage persistente implementado en Q2 2026). Lo que queda es una herramienta con un perfil de uso claro: si tu stack es Supabase, la integración nativa con Postgres y Auth hace que Edge Functions sean la opción obvia para lógica de servidor, webhooks y endpoints de API.

Lo que no resolvieron, y hay que tenerlo presente, es la complejidad de seguridad derivada de la Service Role Key. Ese detalle requiere disciplina de implementación que no viene automática. Pero para equipos que ya entienden el modelo, las 500.000 invocaciones gratuitas por mes y la ausencia de configuración hacen que sea difícil justificar otra alternativa para backends sobre Postgres. Si necesitás infraestructura de hosting confiable para el resto de tu stack, donweb.com tiene opciones de cloud y VPS en Argentina y la región.

Fuentes

• Dev.to — Supabase Edge Functions Review: experiencia en producción con 13 funciones (mayo 2026)
• Supabase Blog — Persistent Storage for Faster Edge Functions (mejoras de performance 2026)
• Supabase Docs — Guía oficial de Edge Functions
• Supabase Docs — Ejemplo: webhooks de Stripe con Edge Functions
• Avarc.nl — Comparativa: Supabase Edge Functions vs Cloudflare Workers