Por qué Supabase y no Firebase
La pregunta clásica de BaaS: Supabase o Firebase. Para el stack StratoAI la respuesta es Supabase por tres razones operativas:
- Postgres en lugar de Firestore. SQL real, queries complejas, joins, agregaciones. Firestore es NoSQL y para muchos casos es regresión.
- Open-source y self-host opcional. Si el cliente quiere ownership futuro, puede mover el proyecto a Postgres self-hosted sin reescribir.
- Row-Level Security tipada y auditable. Política a nivel BD, no a nivel código. Más seguro y más mantenible.
Firebase tiene casos donde gana (apps móviles con sync intensivo, real-time chat trivial). Para MicroSaaS web operados por StratoAI, Supabase es default.
◆ Verdict de operador. Supabase es la pieza que hace MicroSaaS rentable para operador singular. 25$/mes te da Postgres + Auth + Storage + Edge Functions + RLS por proyecto. Lo que en stack tradicional cuesta semanas de wiring está aquí en horas.
Para qué sirve y para qué no
Para qué SÍ
- MicroSaaS con frontend que habla con DB directamente protegido por RLS.
- Productos que necesitan auth + storage + realtime listos sin construir.
- PoC rápidos donde levantar Postgres + Express + Passport es overkill.
- Edge functions ligeras integradas con la DB.
- Stack Astro/React/Next + Supabase es combo productivo y barato.
Para qué NO
- Apps con lógica server-side compleja que no encaja con SQL puro y RLS — sigues necesitando Node/Python al lado.
- Compliance estricto sin opción enterprise con data residency Europa garantizada.
- Volumen industrial extremo donde self-host Postgres da mejor TCO.
- Queries muy complejas donde RLS introduce overhead serio.
Encaje en stack StratoAI
| Línea StratoAI | Cómo se usa |
|---|---|
| MicroSaaS | Backend default cuando el caso encaja con BaaS. Auth + RLS + Storage + queries directas desde frontend. |
| Automations | Edge functions disparadas por triggers de tabla cuando la lógica es ligera y vive cerca de los datos. |
Pricing real (2026-05)
- Free · 500MB DB, 1GB storage, 50.000 monthly active users. Generoso para PoC.
- Pro · 25$/mes/proyecto — 8GB DB, 100GB storage, point-in-time recovery, soporte. La opción para producto serio.
- Team · 599$/mes — multi-proyecto, SSO, audit log.
- Enterprise · a medida — SLA, data residency, dedicated.
Comparativa real: producto MicroSaaS típico de StratoAI corre en Pro 25$/mes durante toda la fase de validación. Cuando crece a Team es señal positiva — el producto está funcionando.
Alternativas reales
| Alternativa | Cuándo elegirla en lugar de Supabase |
|---|---|
| Firebase | Apps móviles con sync intensivo, chat real-time trivial, ecosistema Google profundo. |
| PocketBase | Self-host single-binary austero. Cero coste mantenimiento mínimo. Ideología minimal. |
| Appwrite | Open-source self-host con UX más cercana a Firebase. |
| Postgres self-hosted + Express | Volumen alto + ownership total + equipo capaz de mantener. Más TCO. |
| Convex | Reactive backend tipado para apps React/Next muy interactivas. |
Casos de uso reales en ChefBusiness Group + StratoAI
- GastroPro · SaaS gestión gastronómica en migración Manus → Supabase + Vercel.
- MicroSaaS clientes StratoAI · stack default cuando el caso encaja con BaaS (auth + RLS + queries directas).
- Auth + RLS para productos con auto-onboarding sin backend custom (cliente final se registra y cada uno ve solo sus datos).
- Storage de assets generados por agentes IA · PDFs de informes, imágenes generadas, exports Excel de auditorías.
◇ Regla de uso operativo. RLS desde día uno — política a nivel tabla, no a nivel código. Backups Pro para producto serio (point-in-time recovery). Edge functions para lógica ligera; cuando crece, mover a backend dedicado. NUNCA exponer service_role key en cliente — solo anon key + RLS, service role queda server-side.
