Supabase Postgres 14 termina pronto: checklist antes del auto-upgrade
El plazo ya no es abstracto. Supabase dejará de soportar Postgres 14 el 1 de julio de 2026. Los proyectos que sigan en una versión deprecada serán actualizados automáticamente a la versión disponible más reciente; si usan extensiones no soportadas, pueden quedar pausados y dejar de servir tráfico.
Por qué importa ahora
PostgreSQL upstream mantiene Postgres 14 hasta el 12 de noviembre de 2026, así que la fecha de Supabase llega antes. Para una plataforma gestionada tiene sentido reducir combinaciones antiguas, pero para un equipo de producto significa revisar dependencias reales, no solo la versión.
Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.
Qué cambió
La documentación de Supabase recomienda el upgrade in-place con `pg_upgrade` para muchos proyectos. Suele ser más rápido que pausar y restaurar, pero sigue implicando downtime. Por eso la planificación de ventana y las pruebas de aplicación son parte del trabajo.
| Surface | Example | Why it matters |
|---|---|---|
| Version | `select version();` | Do not rely on memory or project age. |
| Extensions | plv8, timescaledb, pgjwt, pg_cron | Extension compatibility decides whether automation is safe. |
| Roles | custom login roles | Passwords for custom roles may need manual handling. |
| Replication | logical replication slots | Slots may need to be recreated after upgrade. |
| Validation | auth, RLS, jobs, webhooks | Application smoke tests catch what platform checks cannot. |
Señales de la comunidad
La conversación en comunidades se concentra en extensiones, `pg_cron`, roles personalizados, replication slots e integraciones externas. No son fuentes de política, pero sí señales útiles de lo que preocupa a quienes ya están migrando.
Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.
Impacto en desarrollo y operaciones
Empieza con `select version();`, inventaría extensiones, roles, trabajos programados, replicación y clientes externos. Prueba en staging o en una copia restaurada, define pruebas smoke y decide antes quién puede detener o revertir el cambio.
Qué hacer ahora
Upgrade readiness checklist
✓Ejecutar y guardar `select version();`.
✓Revisar extensiones, `pg_cron`, roles y contraseñas.
✓Documentar replication slots y clientes externos.
✓Probar el upgrade en staging o una copia.
✓Preparar smoke tests de auth, RLS, webhooks, jobs y admin.
✓Definir ventana, rollback y ruta de soporte.
Un proyecto pequeño quizá sobreviva con el auto-upgrade. En producción, la automatización no conoce tus contratos de aplicación. El objetivo es quitar condiciones de fallo antes de que la fecha de plataforma las fuerce.
Riesgos y matices
Un proyecto pequeño quizá sobreviva con el auto-upgrade. En producción, la automatización no conoce tus contratos de aplicación. El objetivo es quitar condiciones de fallo antes de que la fecha de plataforma las fuerce.