Supabase Postgres 14 종료 D-13: 자동 업그레이드 전에 점검할 것
데이터베이스 업그레이드는 보통 “언젠가 해야 할 일”로 밀립니다. 이번에는 날짜가 먼저 움직입니다. Supabase는 2026년 7월 1일부터 Postgres 14 지원을 종료한다고 공지했고, 그 날짜에 여전히 deprecated 버전을 쓰는 프로젝트는 최신 사용 가능 버전으로 자동 업그레이드된다고 설명했습니다. 더 중요한 문장은 그 다음입니다. 더 이상 지원되지 않는 확장을 쓰는 프로젝트는 자동으로 올라가지 않고 일시 정지될 수 있으며, 그 동안 트래픽을 처리하지 못할 수 있습니다.
왜 지금 봐야 하나
PostgreSQL 자체의 Postgres 14 EOL은 2026년 11월 12일로 안내되어 있습니다. 즉 Supabase의 운영 기한은 upstream EOL보다 빠릅니다. 플랫폼이 보안·운영 표면을 먼저 정리하는 것은 이상한 일이 아니지만, 애플리케이션 팀 입장에서는 “나중에 해도 되는 메이저 업그레이드”가 아니라 “2주 안에 영향 범위를 확인해야 하는 운영 작업”이 됩니다.
Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.
무슨 일이 바뀌었나
Supabase의 업그레이드 문서는 두 가지 경로를 제시합니다. 일반적으로는 `pg_upgrade` 기반 in-place upgrade가 더 빠르고 안정적인 경로이며, 프로젝트 크기가 커질수록 pause and restore보다 유리하다고 설명합니다. 다만 이 경로도 무중단은 아닙니다. 문서는 적절한 다운타임 창을 계획하고, 업그레이드 중 데이터베이스와 관련 서비스가 사용할 수 없음을 전제로 잡으라고 안내합니다.
| 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. |
커뮤니티 신호
커뮤니티에서는 이미 “공지에 자동 업그레이드와 확장 조건이 같이 적혀 있는데 놓치기 쉽다”는 식의 운영 경험 공유가 나오고 있습니다. Reddit 글 하나를 사실의 근거로 삼을 수는 없지만, 개발자들이 실제로 걱정하는 지점은 분명합니다. 데이터 크기보다 더 자주 발목을 잡는 것은 `plv8`, `timescaledb`, `pgjwt`, `pg_cron` 기록, 커스텀 role 비밀번호, logical replication slot 같은 주변 의존성입니다.
Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.
개발·운영 영향
작은 사이드 프로젝트라면 자동 업그레이드로 끝날 수도 있습니다. 그러나 로그인, 결제, 웹훅, 리포팅, AI feature store처럼 Postgres를 서비스 제어면으로 쓰는 팀은 다릅니다. DB 메이저 업그레이드는 ORM 타입, RLS 정책, 확장 함수, connection pooler, 배치 작업, GraphQL introspection, 읽기 복제, 관측성 쿼리까지 건드립니다. 업그레이드 버튼을 누르기 전보다 누른 뒤에 무엇을 확인할지가 더 중요합니다.
지금 할 일
Upgrade readiness checklist
✓SQL Editor에서 `select version();` 결과를 캡처한다.
✓Dashboard에서 Postgres/PostgREST 버전과 업그레이드 가능 상태를 확인한다.
✓사용 중인 확장, `pg_cron` 기록 크기, custom role 비밀번호 방식을 점검한다.
✓logical replication slot과 외부 ETL/BI 연결을 재생성할 절차를 적는다.
✓스테이징에서 로그인, RLS, 결제 웹훅, 배치, 관리자 화면을 smoke test한다.
✓다운타임 공지, 롤백 판단 기준, Supabase support 연락 경로를 정한다.
오늘 할 일은 단순합니다. 먼저 SQL Editor에서 `select version();`으로 실제 버전을 확인합니다. 다음으로 사용 중인 확장과 custom role, logical replication, cron job, 외부 BI/ETL 연결을 적습니다. 스테이징 또는 복제 환경에서 업그레이드를 먼저 돌리고, 애플리케이션 레벨 smoke test를 문서화합니다. 마지막으로 고객 영향이 가장 작은 시간대에 다운타임 창을 잡고, 실패 시 원래 DB가 다시 올라오는 조건과 지원 연락 경로를 팀 안에 공유합니다.
리스크와 반론
반론도 있습니다. “Supabase가 자동으로 해준다는데 굳이 지금 건드릴 필요가 있나?”라는 생각은 작은 프로젝트에서는 합리적일 수 있습니다. 하지만 확장을 쓰거나 데이터가 커졌거나, 외부 통합이 많은 프로젝트라면 자동화가 리스크를 없애는 것이 아니라 리스크가 터지는 시점을 대신 정하는 것에 가깝습니다. 이번 작업의 목표는 최신 버전 자랑이 아니라, 플랫폼 기한이 오기 전에 장애 조건을 제거하는 것입니다.