Supabase 무료 플랜 일시정지, cron 우회로 자동 해제되는지 실제 확인하는 방법

무료로 백엔드 쓰다가 갑자기 API가 먹통이 됐을 때, 그 황당함 알죠? Supabase 무료 플랜을 쓰는 개발자라면 한 번쯤 맞닥뜨리는 상황이에요. 열심히 만들어놓은 프로젝트, 2주 뒤 접속해보니 DB가 완전히 멈춰있는 거예요.

그냥 방치하면 프로젝트가 멈추고, 재시작하면 로딩 시간이 걸리고. 반복이에요. 이 글에서는 Supabase 무료 플랜 자동 일시정지 정책이 어떻게 작동하는지, cron 우회가 실제로 효과가 있는지, 그리고 자동 해제가 제대로 되는지 확인하는 방법까지 정리할게요.

Key Takeaways

• Supabase 무료 플랜은 7일 동안 활동이 없으면 프로젝트가 자동 일시정지(pause)되며, 이는 공식 정책이에요.
• pg_cron 또는 외부 cron 서비스로 주기적인 DB 쿼리를 실행하면 “활동"으로 인식돼 자동 일시정지를 막을 수 있어요.
• cron이 실제로 작동하는지 확인하려면 cron.job_run_details 테이블을 직접 조회해야 해요.
• 완전히 일시정지된 프로젝트는 cron이 실행될 환경 자체가 없으므로, 외부 서비스와 내부 pg_cron을 조합하는 게 가장 안정적이에요.

자동 일시정지, 정확히 어떻게 작동하나요?

Supabase 공식 문서에 따르면, 무료 플랜 프로젝트는 7일간 아무 활동이 없으면 자동으로 일시정지돼요. 여기서 “활동"이란 API 요청, 대시보드 접속, DB 쿼리 등 모든 형태의 인터랙션을 포함해요.

일시정지된 프로젝트는 자동으로 깨어나지 않아요. 직접 Supabase 대시보드에서 “Restore Project” 버튼을 눌러야 해요. 이 과정에서 보통 30초~2분의 콜드 스타트 시간이 생기고, 그 사이에 들어오는 API 요청은 전부 실패해요.

사이드 프로젝트나 내부 도구처럼 트래픽이 산발적인 경우, 7일은 생각보다 빨리 지나가요. 주말에 잠깐 써보고, 다음 주 금요일에 다시 열었더니 이미 멈춰있는 식이에요.

실제로 많은 개발자들이 처음엔 “버그인 줄 알았다"고 해요. 버그가 아니에요. 설계된 제한이에요.

cron 우회, 실제로 작동하나요?

결론부터 말하면, 작동해요. 단, 설정 방식에 따라 효과가 달라져요.

pg_cron으로 내부에서 해결하기

Supabase는 PostgreSQL 기반이라 pg_cron 익스텐션을 기본 지원해요. 이걸 쓰면 DB 내부에서 주기적인 쿼리를 실행할 수 있어요.

-- pg_cron 활성화 (Supabase 대시보드 > Extensions에서도 가능)
CREATE EXTENSION IF NOT EXISTS pg_cron;

-- 매일 자정에 ping 역할의 쿼리 실행
SELECT cron.schedule(
  'keep-alive-job',
  '0 0 * * *',
  $$ SELECT 1 $$
);

매일 한 번 DB 쿼리가 실행되고, Supabase는 이를 “활동"으로 인식해요. 7일 카운터가 초기화되는 거예요.

그런데 여기서 중요한 함정이 하나 있어요.

pg_cron은 프로젝트가 이미 살아있을 때만 실행돼요. 프로젝트가 일시정지된 상태라면 DB 자체가 꺼져 있는 거라, pg_cron도 당연히 돌지 않아요. 그래서 pg_cron만으로는 “이미 멈춘 프로젝트"를 자동으로 되살릴 수 없어요.

외부 cron 서비스로 보완하기

이 한계를 극복하려면 외부에서 HTTP 요청을 날리는 방식을 병행해야 해요. 대표적인 선택지를 비교해볼게요.

Uptime Robot이나 Cron-job.org는 무료 플랜으로도 5~10분 간격 HTTP 핑이 가능해요. Supabase의 REST API 엔드포인트나 Edge Function에 GET 요청을 보내는 것만으로도 프로젝트를 깨어있게 할 수 있어요. 설정도 5분이면 끝나요.

GitHub Actions의 schedule 트리거는 무료지만, GitHub이 퍼블릭 저장소의 cron을 임의로 지연시키거나 건너뛸 수 있어요. 미션 크리티컬한 용도엔 권장하지 않아요.

실제 작동 확인하는 방법

설정했다고 끝이 아니에요. Supabase SQL Editor에서 아래 쿼리를 직접 실행해보세요.

SELECT
  jobname,
  status,
  return_message,
  start_time,
  end_time
FROM cron.job_run_details
ORDER BY start_time DESC
LIMIT 10;

status가 succeeded로 찍히고 start_time이 최근이면 정상 작동 중이에요. failed거나 결과가 아예 없다면 job이 등록되지 않았거나 익스텐션이 비활성화된 거예요.

Supabase 공식 트러블슈팅 문서에 따르면, 가장 흔한 실패 원인은 두 가지예요:

1. pg_cron 익스텐션이 활성화되지 않은 경우
2. cron.schedule() 함수를 postgres 스키마가 아닌 다른 역할로 실행한 경우

확인은 간단해요. 대시보드 → Database → Extensions → pg_cron 활성화 여부 체크. 이게 먼저예요.

실제 적용 시 알아야 할 것들

트래픽이 산발적인 사이드 프로젝트라면 이렇게 조합하는 게 가장 안정적이에요:

• pg_cron으로 매일 DB 내부 핑 (SELECT 1 수준)
• Uptime Robot 무료 플랜으로 5분마다 외부 HTTP 핑

pg_cron이 살아있는 동안은 내부에서 활동을 유지하고, 혹시 프로젝트가 멈췄더라도 외부 핑이 재시작을 트리거할 수 있어요.

단, 주의할 점이 있어요. 일시정지된 프로젝트에 REST API 요청이 들어오면 Supabase가 자동으로 깨우도록 시도하지만, 이 자동 복구는 Supabase 내부 인프라 상태에 따라 즉시 안 될 수 있어요. 그러니 가장 확실한 건 아예 7일 이전에 활동을 만들어두는 거예요.

참고로 Supabase는 2026년 들어 무료 플랜 정책을 여러 번 조정했어요. 반드시 Supabase 공식 가격 정책 페이지에서 현재 기준을 직접 확인하세요.

정리하면

• Supabase 무료 플랜 자동 일시정지(7일) 정책은 설계된 제한이에요
• pg_cron은 내부 활동 유지에 효과적이지만, 이미 멈춘 프로젝트는 살리지 못해요
• 외부 cron 서비스(Uptime Robot, cron-job.org)와 함께 쓰면 안정성이 올라가요
• cron.job_run_details 테이블 조회로 실제 작동 여부를 반드시 확인해야 해요

자동 해제가 안 된다고 당황하지 마세요. cron 설정한 다음 날, cron.job_run_details를 열어서 초록불이 켜져 있는지 직접 확인해보세요. 그게 가장 확실한 답이에요.

pg_cron 설정 후에도 계속 일시정지가 된다면, 댓글로 어떤 설정을 쓰고 있는지 남겨주세요. 같이 디버깅해볼 수 있어요.

참고자료

1. * 무료 플랜 특징 1. Supabase 무료 플랜은 개인 프로젝트나 학습용으로 충분 2. 가장 중요한 건, 1주일간 활동이 없으면 프로젝트가 자동 중지. 3. 중지된 프로젝트는
2. Scheduling Cron Jobs for Self-Hosted Supabase: A Complete Guide
3. Supabase Docs | Troubleshooting | pg_cron debugging guide

Photo by NASA on Unsplash