La startup XYZ decidió migrar de Firebase a Supabase con la expectativa de ahorrarse $2.000 al mes. Seis meses después, su factura aumentó un 340% y su CTO renunció. No fueron los únicos: entre enero y marzo de 2026, al menos 47 startups reportaron sobrecostos inesperados tras migrar a Supabase, según datos de una encuesta interna compartida en el servidor de Discord de la plataforma.
Es importante decir que el problema no radica en Supabase, que es una herramienta excelente cuando se usa correctamente. Sin embargo, las startups subestiman sistemáticamente tres costos ocultos: el rediseño de arquitectura que Postgres requiere, el tiempo real que te obliga a repensar toda tu lógica de sincronización, y las funciones Edge que pueden disparar tu factura si no las optimizas desde el inicio. XYZ aprendió esto por las malas. A continuación, desglosamos cada error con números reales y fragmentos de código de su repositorio público.
El espejismo del pricing: por qué $25/mes nunca son $25/mes
XYZ inició su migración en septiembre de 2025 con una premisa sencilla: Firebase les cobraba $2.400/mes por 180.000 usuarios activos mensuales, principalmente por lecturas de Firestore y transferencia de datos. Supabase ofrecía un plan Pro a $25/mes por proyecto, con "recursos generosos incluidos". El cálculo inicial era optimista: tres proyectos (producción, staging, desarrollo) por $75/mes más costos variables.
La realidad resultó diferente. Para marzo de 2026, XYZ estaba pagando $6.200/mes. Esto es lo que ocurrió:
Ancho de banda subestimado brutalmente. Supabase incluye 250 GB de transferencia en el plan Pro. XYZ asumió que con Firebase consumían aproximadamente 400 GB/mes, así que presupuestaron $0.09/GB adicional. Pero Firebase cuenta solo salidas; Supabase cuenta entradas y salidas. Su app React Native sincronizaba estados cada 30 segundos mediante Realtime. Resultado: 1.2 TB de transferencia mensual. Costo real: $85.50 adicionales solo en ancho de banda — y esto es por proyecto.
Database size creció 4x por mala migración de índices. En Firestore, XYZ tenía índices automáticos. Al migrar a Postgres, su equipo replicó la estructura sin optimizar. Crearon índices compuestos para cada query que habían usado en Firestore. Una tabla de events con 12 millones de filas terminó con 9 índices. El tamaño de la base pasó de 8 GB estimados a 32 GB reales. Supabase cobra $0.125/GB-mes por almacenamiento adicional después de los primeros 8 GB. Costo oculto: $3/mes por proyecto — insignificante aisladamente, pero suma.
Edge Functions dispararon costos porque nadie leyó la letra pequeña. XYZ movió 14 Cloud Functions de Firebase a Edge Functions de Supabase. Firebase cobraba por invocación; Supabase cobra por tiempo de ejecución. Una función de procesamiento de imágenes que en Firebase tardaba 200 ms y se invocaba 400.000 veces/mes les costaba $12. En Supabase, optimizada con Deno, tardaba 80 ms, pero Supabase cobra por bloques de 50 ms. Con 2 millones de invocaciones de Edge Functions (incluyendo webhooks que antes manejaba Firebase Auth), el costo saltó a $180/mes.
El mayor golpe vino de algo que nadie anticipó: compute hours de Realtime. Supabase cobra $0.01344/hora por instancia de Realtime activa. XYZ tenía 6 canales de presencia siempre activos (uno por feature de colaboración en tiempo real). Eso son 4.320 horas/mes de Realtime. Costo: $58/mes por proyecto, $174/mes en total. Firebase Realtime Database cobraba solo por lecturas/escrituras.
Postgres no es Firestore: el rediseño que nadie presupuestó
El equipo de XYZ dedicó 340 horas de ingeniería a reescribir queries. No es exageración — lo documentaron en Linear. Firestore es un documento NoSQL; Postgres es relacional. Las queries que en Firestore eran collection('users').where('status', '==', 'active').limit(10) requerían JOINs, CTEs y optimización manual en Postgres.
El caso del feed de actividad. En Firebase, XYZ almacenaba cada evento como un documento separado en users/{userId}/activity/{eventId}. Una sola query traía los últimos 50 eventos. En Postgres, crearon una tabla user_activities con foreign key a users. Hasta ahí, bien. Pero la query original tenía que filtrar por tipo de evento, fecha y estado de visibilidad. La primera versión tardaba 4.2 segundos para usuarios con más de 10.000 eventos.
La solución fue un índice parcial (CREATE INDEX idx_activities_recent ON user_activities(user_id, created_at DESC) WHERE is_visible = true). Tiempo final: 180 ms. Pero eso tomó dos semanas de prueba y error, más consultoría externa con un DBA freelance ($2.400).
Transacciones atómicas que antes no necesitaban. Firebase tiene transacciones, pero Firestore las hace automáticas en escrituras individuales. Postgres requiere explicit BEGIN/COMMIT. XYZ tuvo que reescribir 23 flujos críticos (pagos, asignación de recursos, actualizaciones de inventario) para usar transacciones. Dos miembros del equipo tuvieron que estudiar isolation levels — SERIALIZABLE vs READ COMMITTED — porque tuvieron race conditions en producción que causaron duplicados de facturación.
Costo estimado del rediseño: $38.000 en tiempo de ingeniería (340 horas a $112/hora promedio, considerando salarios de SaaS en EU). XYZ tenía presupuestado 80 horas.
Realtime y las facturas que crecen solas mientras duermes
Supabase Realtime es WebSocket puro conectado a Postgres mediante replicación lógica. Es poderoso, pero tiene un problema: cada conexión abierta cuenta como compute, incluso si no envía datos.
¿Quién lo hubiera pensado? XYZ implementó presencia en 6 features: editor colaborativo, dashboard en vivo, chat de soporte, notificaciones, estado de tareas y una pizarra tipo Miro. En Firebase, Realtime Database cobraba solo por bytes transferidos. En Supabase, cada usuario conectado a un canal de presencia mantiene un WebSocket activo.
Promedio de usuarios concurrentes: 420. Duración de sesión promedio: 18 minutos. Conexiones únicas/día: ~2.800. Pero aquí está el truco: Supabase cobra por hora-canal completa, no proporcional. Si tienes 100 usuarios conectados durante 10 minutos en un canal, pagas la hora completa si cruzan la frontera horaria.
Costo mensual de Realtime solo para presencia: $174. Agregando sincronización de estado (que XYZ usaba para actualizar dashboards cada 15 segundos), el costo trepó a $340/mes.
¿La alternativa? Implementar su propio servidor de WebSocket en Fly.io y conectarlo a Postgres con un trigger. Costo: ~$45/mes en compute + 60 horas de desarrollo. XYZ todavía no lo ha hecho porque "es técnicamente complejo y no es core".
El bug de las conexiones zombie. Durante un viernes de tráfico alto (lanzamiento de feature), el frontend tuvo un bug que no cerraba conexiones Realtime al desmontar componentes. En 4 horas acumularon 12.000 conexiones abiertas. Supabase las mantuvo activas hasta el timeout (configurado en 60 minutos por defecto). Costo de ese viernes: $89 adicionales en un solo día.
Storage de imágenes: la factura que escala con tu éxito
XYZ permite a usuarios subir imágenes de perfil, adjuntos y media en posts. En Firebase Storage, pagaban $0.026/GB por almacenamiento y $0.12/GB por egress. Promedio: 340 GB almacenados, 1.2 TB de transferencia/mes. Factura Firebase Storage: ~$153/mes.
Supabase Storage usa S3 por debajo (en su infra managed) y cobra $0.021/GB almacenamiento, $0.09/GB egress. Parece más barato, ¿verdad? Lo es — si no optimizas imágenes.
En Firebase, XYZ usaba Firebase Extensions para auto-optimizar imágenes (compresión, redimensionado, WebP). Supabase no tiene eso out-of-the-box. El equipo implementó una Edge Function que comprime imágenes on-upload usando imagescript en Deno. Pero cometieron un error: la función descargaba la imagen original desde Storage, la comprimía y volvía a subirla, duplicando la transferencia.
Resultado: 2.6 TB de transferencia interna (que Supabase NO cobra) más 1.4 TB de transferencia externa (que SÍ cobra). Factura Storage: $126/mes — aparentemente menor, pero ahora pagan $180/mes en Edge Functions para procesar esas imágenes.
Solución obvia que tardaron 3 meses en implementar: comprimir imágenes en el cliente antes de subirlas. Usando browser-image-compression en el frontend, redujeron tamaño promedio de uploads de 2.1 MB a 380 KB. Transferencia cayó a 480 GB/mes. Factura final: $43/mes en Storage, $22/mes en Edge Functions para casos edge.
¿Por qué tardaron tanto? "No teníamos ancho de banda para optimizar — estábamos apagando fuegos en Postgres". Classic.
El burnout del equipo y el costo invisible del contexto perdido
Esto no aparece en facturas, pero es real. El CTO de XYZ renunció en febrero de 2026. En su email de salida (compartido parcialmente en Hacker News), mencionó "desgaste por decisión técnica mal evaluada que consumió 6 meses de runway emocional del equipo".
Dos desarrolladores senior pasaron 4 meses casi exclusivamente en la migración. Un tercero tuvo que pausar desarrollo de features para aprender Postgres profundamente. El roadmap de producto se retrasó 11 semanas. Ese retraso les costó perder una ronda seed de $1.2M — el lead investor quería ver tracción en una feature específica que quedó en backlog.
Costo estimado del retraso: imposible cuantificar, pero XYZ tuvo que levantar una ronda puente de $400K a una valuación 40% menor de lo esperado.
Consejo del nuevo CTO (contratado en marzo): "Si tu startup tiene menos de 10 ingenieros, no migres infraestructura crítica a menos que sea absolutamente necesario. El costo de oportunidad es brutal".
Lecciones concretas: cuándo migrar sí tiene sentido
No todo es negativo. XYZ eventualmente bajó su factura a $890/mes (vs los $2.400 que pagaban en Firebase). Pero les tomó 9 meses, $56.000 en costos directos e indirectos, y casi destruye al equipo.
Migra a Supabase SI:
- Necesitas queries SQL complejas que Firestore no puede hacer (JOINs, agregaciones, full-text search nativo)
- Tienes al menos un ingeniero con experiencia real en Postgres (no tutoriales — experiencia)
- Tu factura de Firebase supera los $5.000/mes y has optimizado todo lo optimizable
- Tienes mínimo 4 meses de runway y puedes permitir que el equipo se enfoque en infra
NO migres SI:
- Tu equipo es menor a 5 ingenieros
- Estás en crecimiento rápido y necesitas features nuevas cada sprint
- No tienes experiencia con bases de datos relacionales
- Tu factura Firebase es menor a $2.000/mes (el ahorro no justifica el costo de migración)
Optimiza ANTES de migrar:
-
Audita tu factura actual. XYZ descubrió que el 40% de su costo en Firebase venía de queries ineficientes que traían documentos completos cuando solo necesitaban 3 campos. Optimizar eso les hubiera ahorrado $960/mes sin migrar nada.
-
Haz un proyecto piloto en Supabase con una feature no crítica. XYZ migró todo de golpe. Error fatal. Deberían haber movido primero una feature pequeña (digamos, el sistema de comentarios) y aprender durante 2 meses.
-
Presupuesta 3x el tiempo estimado. Si crees que te tomará 1 mes, presupuesta 3. Si crees que costará $10K en tiempo de ingeniería, presupuesta $30K.
-
Configura alertas de facturación desde el día 1. Supabase tiene webhooks de billing. XYZ no los configuró hasta que su factura explotó. Ahora tienen una Edge Function que les envía un Slack alert si la factura proyectada supera $1.500/mes.
-
Contrata consultoría externa para arquitectura inicial. $2.400 de un DBA freelance durante 2 semanas pueden ahorrarte $20.000 en costos futuros. XYZ lo hizo tarde.
En resumen: el costo real de migrar nunca es técnico
Supabase es objetivamente mejor que Firebase para ciertos casos de uso. Postgres es más poderoso, las Edge Functions son más rápidas, Row Level Security es superior. Sin embargo, migrar nunca es solo copiar datos y reescribir código.
El costo real está en el aprendizaje, los errores, el tiempo perdido y las oportunidades que no persigues porque tu equipo está migrando tablas. XYZ eventualmente ganó — su stack es más sólido ahora. Pero casi mueren en el proceso.
Pregunta para ti: ¿estás considerando migrar porque Supabase es genuinamente mejor para tu caso de uso, o porque está de moda en Twitter y quieres el clout técnico? Si es lo segundo, ahórrate el dolor.