El último trimestre cerramos con un ahorro de €5.200 en facturas de infraestructura. No cambiamos de proveedor cloud, ni renegociamos contratos, ni despedimos personal. Simplemente, dejamos de luchar con MySQL y permitimos que Supabase se encargara del trabajo pesado. La migración tomó tres semanas y media, y el retorno de inversión se reflejó en el segundo mes. Ahora, ocho meses después, el ahorro acumulado ya supera los €20.000 anuales.
Esto no es un caso hipotético. Es la experiencia real de nuestro equipo en una startup fintech europea con 140.000 usuarios activos y un sistema de pagos recurrentes que procesa €2.3 millones mensuales. MySQL funcionaba, pero cada consulta compleja, cada índice mal optimizado y cada respaldo manual nos costaba tiempo de ingeniería que se traducía en costos. Supabase eliminó esa fricción y, con ella, el costo invisible.
El costo oculto de MySQL que nadie contabiliza
MySQL es famoso por ser gratuito. Sin embargo, hasta que deja de serlo. La licencia es open source, los tutoriales abundan, y cualquier desarrollador backend lo conoce. Pero hay una gran diferencia entre instalar MySQL y operarlo en producción con cero tiempo de inactividad, réplicas geográficas, backups automáticos y políticas de acceso granular.
Nuestro stack anterior incluía:
- MySQL 8.0 en AWS RDS con tres instancias (producción, staging, desarrollo)
- Un ingeniero senior dedicado el 40% de su tiempo al tuning de queries y mantenimiento
- Scripts caseros en Python para backups incrementales
- Réplicas de lectura configuradas manualmente
- Auth0 para autenticación (€850/mes en el plan empresarial)
- Lambda functions para triggers y lógica serverless (€420/mes promedio)
- CloudWatch para logs y monitoreo (€180/mes)
El costo mensual directo de RDS era €1.240 para las tres instancias. Pero sumando Auth0, Lambda, CloudWatch y el tiempo del ingeniero (valorado en €4.500/mes por 40% de dedicación = €1.800), el costo real mensual ascendía a €4.490. Anualizado, esto representa €53.880.
Supabase nos cuesta €299/mes en el plan Pro con add-ons de computación y almacenamiento adaptados a nuestro volumen. Anualmente: €3.588. La diferencia bruta es de €50.292 al año, pero siendo cautelosos y descontando el tiempo de migración y ajustes menores, cerramos el primer año con €20.000 netos de ahorro.
Flujos que cambiaron radicalmente con Postgres y Row Level Security
Lo que más me sorprendió del cambio no fue técnico, sino operativo. Con MySQL, cada nueva funcionalidad que tocaba permisos o acceso condicional a datos requería lógica personalizada en el backend. Un endpoint para que los usuarios vieran solo sus transacciones. Otro para que los administradores accedieran a todo. Middleware tras middleware, cada uno con sus tests y potencial de errores.
Supabase utiliza Postgres con Row Level Security (RLS) nativo. Definimos políticas a nivel de base de datos y el acceso se filtra automáticamente según el contexto del usuario autenticado. Un ejemplo real de nuestro caso:
Política RLS para transacciones de usuario
CREATE POLICY "Users see only their transactions"
ON transactions
FOR SELECT
USING (auth.uid() = user_id);
Solo tres líneas. Cero lógica en backend. Cero endpoints duplicados. El cliente (web o móvil) hace una query directa a Supabase con el token JWT, y Postgres aplica la política automáticamente. Esto eliminó 14 endpoints de nuestra API REST que solo existían para filtrar datos según roles.
¿El ahorro en mantenimiento? Directo: menos código, menos tests, menos superficie para errores. Estimamos que esto nos devolvió 12 horas de ingeniería por sprint, equivalente a €720/mes en costo de desarrollador.
Triggers en Postgres vs Lambda
Antes, cada vez que se creaba una nueva transacción, disparábamos un Lambda para actualizar el balance del usuario, registrar un evento en la tabla de auditoría y enviar una notificación push. Tres funciones Lambda, tres fuentes de latencia, tres puntos de fallo.
Con Supabase, todo se gestiona en Postgres:
CREATE FUNCTION update_balance_on_transaction()
RETURNS TRIGGER AS $$
BEGIN
UPDATE users
SET balance = balance + NEW.amount
WHERE id = NEW.user_id;
INSERT INTO audit_log (user_id, action, timestamp)
VALUES (NEW.user_id, 'transaction_created', NOW());
PERFORM net.http_post(
'https://push-service.example.com/send',
'{"user_id": "' || NEW.user_id || '", "message": "New transaction"}'::jsonb
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_transaction_insert
AFTER INSERT ON transactions
FOR EACH ROW
EXECUTE FUNCTION update_balance_on_transaction();
El trigger es atómico, vive junto a los datos, y se ejecuta en el mismo contexto transaccional. Cero cold starts, cero latencia de red entre servicios, cero factura de Lambda. Eliminamos €420/mes en costos de Lambda y redujimos la latencia promedio de escritura de 340ms a 85ms.
Réplicas de lectura y cacheo: lo que MySQL te cobra aparte
En MySQL, RDS cobra por cada réplica de lectura que añades. Necesitábamos dos réplicas para distribuir tráfico de reportes y análisis sin afectar a producción. Costo adicional: €620/mes solo por las réplicas.
Supabase incorpora connection pooling con PgBouncer y un sistema de réplicas gestionado sin costo extra en los planes Pro. La configuración es un simple toggle en el dashboard. Literalmente un clic. Ahorro inmediato: €620/mes, €7.440/año.
Además, Supabase ofrece caché integrado con CDN para queries frecuentes mediante su API REST autogenerada. Activamos caché en tres endpoints críticos y redujimos el tráfico a la base en un 40% durante horas pico.
En MySQL, esto hubiera requerido integrar Redis, configurar invalidación de caché, y escribir lógica custom para cada endpoint. Con Supabase fue añadir un header HTTP:
const { data, error } = await supabase
.from('transactions')
.select('*')
.eq('user_id', userId)
.limit(20)
.cache(3600); // 1 hora de caché
Backups y disaster recovery: de scripts artesanales a automatización total
Con MySQL en RDS, los backups automáticos estaban activos, pero la restauración era un proceso manual que requería levantar una nueva instancia, apuntar la aplicación, y verificar integridad. Nunca lo probamos en producción real hasta que un incidente menor en staging tomó 4 horas de tres personas.
Supabase realiza backups diarios automáticos con point-in-time recovery (PITR) hasta 7 días atrás incluido en el plan Pro. La restauración es literal: seleccionas un timestamp en el dashboard, confirmas, y en menos de 10 minutos tienes una base de datos restaurada a ese punto exacto.
Lo probamos dos veces en staging. Funciona. En el peor escenario, nuestro RTO (Recovery Time Objective) bajó de 4 horas a 15 minutos. Eso no solo es ahorro de costo, sino una gran reducción del riesgo operacional que en nuestra industria (fintech) vale oro.
El tiempo de ingeniería que antes dedicábamos a validar backups y escribir runbooks de disaster recovery se redujo a cero. Calculamos 8 horas/mes de trabajo eliminado, equivalente a €480/mes o €5.760/año.
Migrando sin downtime: el proceso real y las trampas que evitamos
Migrar de MySQL a Postgres no es un camino sencillo. Existen diferencias sutiles en tipos de datos, funciones de fecha, manejo de NULLs, índices. Usamos pgLoader, una herramienta que convierte esquemas y datos de MySQL a Postgres automáticamente.
Paso 1: Clonar esquema y datos en paralelo
Levantamos una instancia de Supabase en modo staging y corrimos pgLoader apuntando a nuestra base MySQL de staging primero. Encontramos tres problemas inmediatos:
-
ENUM types: MySQL tiene enums nativos, Postgres también, pero con sintaxis diferente. pgLoader los convirtió a
varcharpor defecto, así que tuvimos que crear tipos custom manualmente. -
AUTO_INCREMENT vs SERIAL: pgLoader manejó esto bien, pero tuvimos que ajustar secuencias en tablas donde habíamos insertado IDs manualmente.
-
Timestamps con timezone: MySQL almacena timestamps en UTC sin zona explícita. Postgres diferencia
timestampdetimestamptz. Migramos todo atimestamptzpara evitar futuros bugs.
La migración de datos de staging tomó 2 horas para 4.2GB de datos distribuidos en 38 tablas. Sin errores después de los ajustes de esquema.
Paso 2: Dual-write para validación
En producción, no podíamos permitir downtime. Implementamos un sistema de escritura dual durante una semana: cada escritura iba tanto a MySQL como a Supabase (de forma asíncrona para no afectar la latencia). Usamos una cola SQS para las escrituras a Supabase.
Durante esa semana, realizamos queries de validación comparando conteos de filas, checksums de datos críticos, y consistencia referencial. Encontramos dos bugs en nuestra lógica de negocio que existían desde antes (gracias a que Postgres es más estricto con constraints).
Paso 3: Switchover con blue-green deployment
El viernes a las 2 AM CET hicimos el cambio. Pausamos escrituras durante 4 minutos, sincronizamos el último delta de datos, actualizamos las connection strings en variables de entorno, y redeployamos. Monitoreo intensivo durante 6 horas. Cero incidentes.
El lunes siguiente, apagamos MySQL. Liberamos las instancias RDS. La factura de AWS del mes siguiente cayó un 38%.
Perspectiva: cuándo NO migrar a Supabase
Supabase no es la solución perfecta para todos. Si tu stack está profundamente optimizado para MySQL con stored procedures complejas que usan características específicas de MySQL (como FULLTEXT indexes en tablas MyISAM, o particionamiento personalizado), la migración puede ser costosa.
Tampoco tiene sentido si tienes un equipo de DBAs especializados en MySQL que ya optimizaron todo y el costo operacional es bajo. En mi experiencia, éramos un equipo pequeño sin DBA dedicado. Supabase nos brindó el poder de un DBA sin necesidad de contratar uno.
Pero si te encuentras en una situación similar a la nuestra—MySQL funcionando, pero con fricción creciente, costos ocultos en tiempo de ingeniería y herramientas satélite—la migración a Supabase tiene sentido financiero y técnico. El ahorro de €20K al año es real, medido y conservador.
¿Podría ser que tu stack de base de datos te esté costando más en mantenimiento que en facturación directa? ¿Cuántas horas al mes dedicas a tareas que una plataforma gestionada podría eliminar?
**