Stack backend para un fundador solo: cómo elegir Cloudflare Workers, Supabase, Node.js y base de datos

"Cloudflare publica límites distintos de solicitudes, CPU, memoria, subrequests y tamaño para Workers Free y Paid, sin duración HTTP fija mientras el cliente siga conectado."
El frontend está listo. Ahora debes implementar /api/submit, /api/checkout-webhook y /api/report-cron, además de almacenar users, usage_events y files. ¿Qué va en Workers, qué en Supabase y qué requiere un servicio Node separado?
Un stack backend no es una única plataforma. Entrada de solicitudes, datos de negocio, archivos, tareas largas, autenticación y webhooks se distribuyen. Workers sirve para edge y lógica ligera, Supabase para Auth y Postgres, y Node.js para trabajo pesado y dependencias fuera del runtime edge. Compara esta tabla con tu backlog.
1. Tabla de responsabilidades: dónde va cada elemento
Empieza con API, webhooks, cron, datos y archivos:
| Responsabilidad | Inicio recomendado | Motivo | Riesgo |
|---|---|---|---|
| Entrada | Cloudflare Workers | Edge global y baja latencia | Separar lo que exceda CPU, memoria o dependencias |
| API ligeras | Workers / Edge Functions | Reenvío, validación e I/O corto | Workers está más cerca del edge; Edge Functions del proyecto Supabase |
| Webhooks | Workers o Edge Functions | Callbacks, firma y escritura idempotente | Encolar el trabajo pesado |
| Autenticación | Supabase Auth | Auth, RLS, permisos y login social | No exponer service role ni secret al navegador |
| Datos de negocio | Supabase Postgres | Relaciones, transacciones, consultas y triggers | D1 u otra base también exige migraciones, constraints y permisos |
| Objetos | Supabase Storage / R2 | Cargas, imágenes, exportaciones y copias | Elegir por acceso, egress, CDN y herramientas |
| Tareas largas | Worker Node.js / plataforma de tareas | Navegador, archivos, módulos nativos, consumers | No ligar todo a una solicitud síncrona |
| Servicio Node | Node.js | npm, conexiones largas y runtime completa | Operar despliegue, monitoreo, parches y escalado |
La tabla no propone meter todo en Workers. Workers tiene límites; Supabase, cuotas y pausas; Node.js, operación continua. Puedes retrasar Node, pero debes reconocer la señal.
Decidir dónde viven los datos
- Datos de negocio → Supabase Postgres u otra base relacional para relaciones, transacciones, consultas, triggers y claves foráneas.
- Archivos → Supabase Storage o R2 según permisos, egress, CDN, región y herramientas.
- Caché → KV; D1 puede guardar datos relacionales ligeros, sin sustituir la fuente de verdad.
La comparación D1, Postgres, R2, S3 y SQLite corresponde al artículo de almacenamiento. Aquí solo asignamos categorías.
Separar webhook y tarea larga
Stripe o GitHub pueden llegar a Workers o Edge Functions. El handler valida la firma, guarda idempotencia y responde. Navegador, archivos grandes o esperas externas siguen en Queue, Workflow, Container o Node.js.
Workers Paid ofrece 30 segundos de CPU HTTP por defecto, configurables hasta 5 minutos; un Cron al menos horario puede usar 15 minutos. HTTP no tiene límite de reloj fijo mientras el cliente siga conectado, pero desconexiones, reintentos, recursos y actualizaciones hacen frágil una tarea larga ligada a la solicitud.
Alertas de los planes gratuitos
En julio de 2026, Workers Free incluye 100.000 solicitudes diarias, 10 ms de CPU, 128 MB y 50 subrequests. Supabase Free incluye 50.000 MAU, 500 MB de base, 5 GB de egress, 1 GB de archivos y dos proyectos activos.
Son presupuestos iniciales, no promesas. Supabase pausa tras una semana sin actividad y Workers exige Paid al superar Free. Con usuarios o pagos estables, añade alertas, costos y degradación.
2. Cloudflare Workers: qué encaja y qué no
Workers no es universal. Sus límites reales son CPU, memoria, subrequests y bundle.
Límites Workers Free en julio de 2026
Permite 100.000 solicitudes al día y 10 ms de CPU. La memoria es 128 MB, 50 subrequests y 3 MB comprimidos. El exceso de CPU devuelve 1102. HTTP no tiene reloj fijo con el cliente conectado; ctx.waitUntil() prolonga hasta 30 segundos tras respuesta o desconexión.
Límites Workers Paid Standard
Cuesta al menos 5 dólares por cuenta al mes e incluye 10 millones de solicitudes y 30 millones de ms CPU. CPU HTTP: 30 segundos por defecto, hasta 5 minutos. Extras: 0,30 dólares por millón de solicitudes y 0,02 por millón de ms. Permite 10.000 subrequests, 10 MB y 128 MB.
Casos adecuados
- Entrada, proxies edge y API ligeras.
- Webhooks, firmas e inserción idempotente en cola.
- Cron, Queues y Workflows.
- KV/R2, caché, redirecciones y A/B.
Predominan I/O, validación y orquestación, sin cargar archivos grandes ni iniciar navegador o bibliotecas nativas.
Casos inadecuados
- CPU sostenida → dividir, asíncrono o Node.js/Container.
- Archivos completos en memoria → stream o carga directa.
- Navegador largo → Node.js con Playwright/Puppeteer.
- Dependencias fuera del runtime → Node.js o contenedor.
La compatibilidad Node de Workers cubre muchas API, pero compilar no implica ser adecuado. Evalúa recursos, reintentos, duración y observabilidad.
Alerta de costo
A 5 ms, 10 millones de solicitudes consumen 50 millones de ms CPU. Tras 30 millones incluidos, el extra es unos 0,40 dólares, además de KV, Queues o R2.
La alerta importante es una función central que solo funciona dentro del cupo gratuito. Prepara límite, caché y fallback si el exceso rompe margen o disponibilidad.
3. Supabase: límites de Auth, Postgres, Storage y Edge Functions
Supabase reúne Postgres, Auth, Storage, Realtime y Edge Functions, cada uno con límites.
Límites Supabase Free en julio de 2026
Ofrece 500 MB de base, 50.000 MAU, 5 GB de egress, 5 GB de egress cacheado y 1 GB de archivos por proyecto, con dos proyectos activos. Tras una semana sin actividad se pausa: sirve para validar, no garantiza producción.
Cupo Supabase Pro
Empieza en 25 dólares al mes: 100.000 MAU, 8 GB de disco, 250 GB de egress, 250 GB cacheados y 100 GB de archivos. Incluye 10 dólares de créditos compute; proyectos, recursos y extras aumentan el costo.
Casos adecuados
- Usuarios: email, OAuth, sesiones y RLS.
- Datos: relaciones, constraints, transacciones y consultas.
- Archivos con políticas de acceso.
- Triggers, funciones y migraciones Postgres.
- Edge Functions ligadas a Auth, Postgres y Storage.
Si la lógica escribe datos del usuario, actualiza filas o registra uploads, Supabase reduce componentes operados.
Límites de Edge Functions
Runtime TypeScript/Deno para webhooks e integraciones: 256 MB, 2 segundos CPU por solicitud y 150 segundos de idle timeout. Duración máxima: 150 segundos Free y 400 Paid.
El reloj incluye espera I/O, no CPU. Navegador, multithreading nativo, video y archivos grandes van a workers dedicados. Background tasks conservan los mismos límites.
Edge Functions o Workers
- Lógica ligada a Supabase → Edge Functions.
- Entrada edge o proxy independiente → Workers.
Un webhook que actualiza suscripciones encaja en Edge Functions; firma, rate limit y reenvío en Workers. Lo largo se encola.
Pausa del proyecto
Supabase pausa Free tras una semana inactivo. Una herramienta ocasional puede esperar al reanudarse; un producto estable debe evaluar Pro, backups y migración.
4. Node.js: cuándo sigue siendo útil
Serverless reduce mantenimiento, pero no elimina runtimes completas, dependencias del sistema y procesos persistentes.
Cuándo usar Node.js
- Playwright o Puppeteer.
- Archivos grandes, parsing y disco temporal.
- Módulos nativos o npm incompatible con edge.
- Consumers persistentes, WebSockets y API admin.
- Backend compartido con recursos y observabilidad uniformes.
Capturas, PDF, recolección, video y archivos grandes suelen necesitar más CPU, memoria, procesos o filesystem.
Señales para Node.js
Evalúalo al chocar repetidamente con CPU, memoria, duración, bundle o compatibilidad, o necesitar navegador, módulos nativos, conexión persistente o cola confiable.
No uses solo «más de 30 segundos». Cada producto tiene límites distintos; importa si el trabajo cabe en su modelo de recursos, reintentos, idempotencia y observabilidad.
Cuándo no usar Node.js
- Reenvío de API o routing edge.
- Validación y escrituras I/O ligeras.
- Sin archivos pesados, dependencias nativas ni conexiones largas.
- Sin demanda que justifique operar servidor.
Workers o Edge Functions cubren estos casos.
Node.js no está obsoleto
Edge cambia restricciones por poca operación y distribución; Node.js cambia infraestructura por compatibilidad, control y procesos persistentes. Son responsabilidades distintas. Añádelo cuando navegador, archivos o dependencias sean reales.
5. Workers y Supabase: API client o Hyperdrive
Forman una stack de entrada edge más identidad y datos, no necesariamente rivales.
Combinar Workers y Supabase
Workers gestiona reenvío, validación, rate limit y caché; Supabase Auth y Postgres, identidad, datos y policies. Es adecuado para el primer producto sin servidor.
Para Auth, Data API o Storage basta supabase-js. Para SQL, transacciones u ORM frecuentes, usa driver y pool en vez de una conexión nueva por invocación.
Tabla de conexiones
| Método | Caso | Nota |
|---|---|---|
| Supabase JS Client | Auth, Storage y consultas ligeras | Conserva JWT y RLS mediante API |
| Hyperdrive + driver | SQL, ORM y Postgres directo | Agrupa conexiones y puede cachear lecturas |
| service role / secret key | Administración confiable | Puede omitir RLS; solo cliente servidor aislado |
Hyperdrive reduce latencia y presión al conectar Supabase Postgres. No autoriza: rol, tablas y RLS dependen de credenciales y policies.
Riesgo de service role key
Estas claves son privilegiadas y pueden omitir RLS. Nunca las expongas a navegador, móvil, repositorio o logs; solo como secrets backend.
Usa un cliente servidor separado para que una sesión no reemplace Authorization. Webhooks, batch y admin necesitan privilegio mínimo y auditoría, no una clave universal.
Frontera Edge Functions/Workers
- Dependencia fuerte de Supabase → Edge Functions.
- Entrada, proxy, rate limiting y routing independientes → Workers.
Decide según centro de datos y permisos, funciones edge y lugar de logs/despliegue. La clave privilegiada siempre es backend.
6. Propiedad de datos: negocio, archivos y caché
D1, Postgres, KV y R2 guardan datos, pero resuelven problemas distintos.
Tabla de propiedad
| Tipo | Inicio | Criterios |
|---|---|---|
| Hechos de negocio | Supabase Postgres / D1 / otra relacional | Relaciones, transacciones, constraints, consultas, migraciones y permisos |
| Archivos | Supabase Storage / R2 / S3 | Acceso, egress, CDN, ciclo y herramientas |
| Caché/configuración | KV / Cache | Lectura rápida, reconstrucción y consistencia aceptable |
Usuarios, pedidos, suscripciones, proyectos y permisos afectan cobro o acceso. Van en una base con constraints, migraciones y backup. Postgres aporta consultas, claves, triggers, integridad y MVCC; D1 requiere evaluar consistencia, escala y plataforma.
No dividas archivos por 1 GB. Supabase Storage encaja con Auth/RLS; R2 con tráfico/CDN Cloudflare. Decide por política, egress, carga, transformación y SDK.
El caché no es la base de negocio. KV sirve para configuración y datos reconstruibles. Si pedidos o permisos solo están allí, expiración, retraso o borrado cambia el estado real.
La comparación completa se reserva al artículo de almacenamiento.
7. Siguientes pasos de la serie
Después vendrán despliegue, bases y almacenamiento, pagos, autenticación y autorización.
Artículos relacionados
Consulta Cloudflare Pages, Cloudflare Free Plan Limits 2026, proxy API Workers, inicio con Supabase y Supabase Edge Functions.
Crear primero tu tabla
Lista cinco acciones y marca «respuesta / identidad / hecho / archivo / tarea / secreto»; asígnalas a Workers, Supabase, Node.js o aplázalas. La plataforma es un medio; responsabilidades y fallos definen la fiabilidad.
Repartir las responsabilidades del primer backend de un fundador solo
Parte de las acciones y tipos de datos para asignar API, autenticación, datos, archivos y tareas largas a servicios de bajo mantenimiento.
⏱️ Estimated time: 45 min
- 1
Step 1: Listar acciones
Anota formularios, webhooks de pago, historial, informes programados, cargas y eventos de uso que debes publicar esta semana. - 2
Step 2: Clasificar responsabilidades
Marca cada acción como respuesta inmediata, identidad y acceso, hecho de negocio, archivo, tarea asíncrona o secreto. - 3
Step 3: Elegir el servicio inicial
Coloca entrada edge y API ligeras en Workers, Auth, Postgres y Storage en Supabase, y reserva Node.js para tareas pesadas. - 4
Step 4: Comprobar límites
Revisa CPU, memoria, duración, tamaño de base, egress, archivos y pausas para no apoyar un flujo central en el borde del cupo. - 5
Step 5: Cubrir seguridad y fallos
Mantén las claves fuera del navegador, valida firmas, usa idempotencia y permite reintentos con registros.
FAQ
¿Alcanza Cloudflare Workers Free para empezar?
¿Puede Workers ser todo el backend?
¿Supabase y Workers compiten?
¿Webhook en Workers o Edge Functions?
¿Node.js está obsoleto?
9 min de lectura · Publicado el: 9 oct 2026
Guia de stack tecnico para solo founders
Si llegaste desde búsqueda, lo más rápido es ir al artículo anterior o siguiente de esta misma serie.
Anterior
Stack frontend para un solo founder: cómo elegir Astro, Next.js, React, Tailwind y shadcn/ui
Compara Astro, Next.js, React, Tailwind y shadcn/ui para sitios de contenido, herramientas y paneles SaaS, con límites de mantenimiento y señales de migración.
Parte 5 de 8
Siguiente
Despliegue para solopreneurs: Cloudflare, Vercel o Railway
Compara Cloudflare Pages y Workers, Vercel y Railway por tipo de carga, límites actuales, riesgos de facturación y mantenimiento para un stack en solitario.
Parte 7 de 8



Comentarios
Inicia sesión con GitHub para dejar un comentario