오프테이블 Wiki

조사 결과 · 종합 판단

Supabase·Vercel에서 AWS로 옮길 시점

사용자 수가 아니라 측정된 병목, 가용성 요구와 운영 인력을 함께 충족할 때 단계적으로 AWS로 옮긴다.

상태
검토됨
신뢰도
보통
근거
11개
업데이트

핵심 결론

RN 출시나 MAU 목표만으로 AWS로 옮기지 않는다. Supabase·Vercel을 최적화·확장한 뒤에도 핵심 SLO를 반복해서 못 맞추거나, 필요한 가용성·보안·비용 구조를 AWS가 운영 인력까지 포함해 명확히 개선할 때 실제 병목부터 옮긴다.

목차
  1. 현재 판단
  2. 이전 신호
  3. 권장 단계
  4. 이전 실행 원칙
  5. 권장 결정
문서 정보
상태
검토됨
업데이트
2026-08-12
신뢰도
보통

근거 11

  1. 1Supabase Compute and DiskSupabase · 2026-08-12
  2. 2Supabase Read ReplicasSupabase · 2026-08-12
  3. 3Supabase Realtime LimitsSupabase · 2026-08-12
  4. 4Supabase Storage CDNSupabase · 2026-08-12
  5. 5Vercel CDN OverviewVercel · 2026-08-12
  6. 6Supabase Auth with React NativeSupabase · 2026-08-12
  7. 7Vercel Functions LimitsVercel · 2026-08-12
  8. 8Supabase Database BackupsSupabase · 2026-08-12
  9. 9AWS DMS PostgreSQL SourceAmazon Web Services · 2026-08-12
  10. 10Amazon RDS for PostgreSQLAmazon Web Services · 2026-08-12
  11. 11초기 MVP Supabase·Vercel 개발 결정프로젝트 오너 김의영 · 2026-08-12

연결된 문서 12

현재 판단#

Supabase가 곧바로 대규모 트래픽에 부적합하다는 단정은 현재 공식 기능과 맞지 않는다. 전용 Postgres는 compute·disk·connection pool을 확장할 수 있고 read replica는 읽기 부하와 지역 지연을 줄인다. [1] [2]

다만 Auth·Storage·Realtime은 현재 replica endpoint를 사용하지 못해 DB 읽기 확장만으로 전체 부하를 해결할 수 없다. [2] Realtime 공개 기준은 Pro no-spend-cap·Team에서 동시 연결 10,000과 초당 메시지 2,500이며 Enterprise는 지원을 통한 상향 대상이다. 이는 전체 서비스 처리량이 아니라 Realtime 프로젝트 한도다. [3]

Supabase Storage와 Vercel은 CDN을 제공한다. [4] [5] RN·Expo도 공식 Supabase Auth 흐름을 지원하므로 앱 개발 자체는 이전 사유가 아니다. [6]

이전 신호#

영역 먼저 할 일 AWS 이전 승인 신호
Postgres index·query·N+1·cache·pool 개선, compute·replica 시험 이후에도 핵심 API p95·오류율 SLO를 2주 이상 위반
쓰기 transaction·batch·queue·lock·WAL 개선 6개월 부하 시험에서 허용 구성으로 목표 처리량을 못 맞춤
Realtime 방 단위 구독, presence·broadcast 최소화 상향 협의 뒤에도 연결·메시지 SLO를 못 맞춤
Storage·CDN 변환·cache-control·수명주기 적용 S3·CloudFront의 6개월 TCO와 기능이 명확히 우수
API·batch Vercel cache, 긴 작업 queue 분리 실행시간·지역·runtime 제약이 핵심 기능을 막음
가용성 PITR·복원 훈련·runbook 현재 구조가 확정된 RPO·RTO를 충족하지 못함
비용 DB·Realtime·egress·Functions 단위비용 측정 인건비 포함 AWS TCO가 2개 분기 연속 유의미하게 낮음
보안 RLS·secret·audit·retention 검증 현재 플랫폼으로 확정 요구를 충족할 수 없음

30% 여유, 계약 한도 70%, 2주와 2개 분기는 벤더 기준이 아니라 오프테이블의 초기 경보 제안이다. 실제 기초선 뒤 조정한다.

권장 단계#

  1. MVP·RN 초기: Supabase·Vercel 결정을 유지한다. 웹과 RN이 인증·Postgres·RLS·Storage·Realtime 계약을 공유하고, 제품 핵심 상태는 Postgres에 기록한다.
  2. 초기 성장: query·pool·compute·replica·CDN·cache 순서로 확장한다. Vercel Functions도 큰 동시성 범위를 제공하지만 실행시간·메모리·file descriptor 한도는 workload별로 측정한다. [7]
  3. 이전 준비: PostgreSQL migration과 extension 목록, Auth UID·RLS·Storage URL·Realtime 의존성을 정리하고 AWS 후보를 같은 부하로 시험한다.
  4. 단계 이전: 파일이면 S3·CloudFront, 긴 작업이면 Lambda 또는 ECS/Fargate, DB 병목·복구 요구면 RDS 또는 Aurora를 먼저 검토한다. Auth·Realtime은 별도 프로젝트로 취급한다.

Supabase 유료 프로젝트는 일일 백업을 제공하고 PITR을 선택할 수 있지만 복원 중 접근이 중단된다. [8] RPO·RTO와 개인정보 운영은 안전·운영 기준에 맞춰 실제 복원 시험으로 확인한다.

이전 실행 원칙#

AWS DMS는 PostgreSQL full load와 CDC를 지원한다. 다만 logical replication slot의 WAL이 source disk를 늘릴 수 있어 공간 경보, dual-read 검증, 짧은 write freeze와 rollback 조건이 필요하다. [9]

RDS PostgreSQL도 Multi-AZ, read replica, Provisioned IOPS와 PITR을 제공하지만 host와 일부 고급 권한이 제한되는 관리형 서비스다. AWS는 자동으로 무제한 확장이나 낮은 비용을 보장하지 않는다. [10]

권장 결정#

현재는 AWS 이전을 준비 가능하게 설계하되 실행하지 않는다. 첫 production load test와 실제 peak 기초선을 만든 뒤 다음 중 하나가 성립하면 재검토한다.

  • 최적화·상향 뒤에도 핵심 SLO를 2주 이상 위반
  • 6개월 peak 예측이 계약 한도의 70% 초과
  • 현재 플랫폼으로 충족 불가능한 RPO·RTO·보안·지역 요구 확정
  • migration과 운영 인력을 포함한 AWS TCO가 2개 분기 연속 명확히 유리

재검토가 열려도 전체 이전을 기본값으로 삼지 않고 Storage·worker·DB·Realtime 중 실제 병목부터 분리한다.

제목, 요약, 태그, 본문을 검색합니다.