Supabase는 데이터베이스만이 아닙니다: 핵심 서비스와 Upstash 비교

PostgreSQL부터 인증, 파일 저장, 실시간 통신, 작업 큐와 스케줄러까지 Supabase가 제공하는 기능을 살펴보고, Upstash와 역할이 겹치는 부분을 구분해봅니다.

Supabase를 처음 접하면 관리형 PostgreSQL 서비스로 이해하기 쉽습니다. 실제로 PostgreSQL은 Supabase의 중심이지만, 전체 제품은 데이터베이스보다 훨씬 넓은 범위를 다룹니다.

Supabase 프로젝트에는 전용 PostgreSQL 데이터베이스와 함께 자동 생성 API, 사용자 인증, 파일 저장소, 실시간 통신, 서버리스 함수가 제공됩니다. 최근에는 작업 큐와 Cron까지 같은 플랫폼에서 구성할 수 있어 웹과 모바일 서비스의 백엔드 기반을 한곳에서 마련할 수 있습니다.

이 글에서는 Supabase의 주요 서비스를 먼저 살펴본 다음, 마지막에 Upstash와 기능이 겹치는 지점과 함께 사용하기 좋은 영역을 정리하겠습니다.

Supabase의 전체 구성을 먼저 살펴보겠습니다

Supabase의 주요 기능은 다음과 같이 나눌 수 있습니다.

Supabase
├─ Database        PostgreSQL과 확장 기능
├─ Auth            로그인과 사용자 관리
├─ Storage         이미지·영상·문서 저장
├─ Realtime        Broadcast·Presence·DB 변경 구독
├─ Edge Functions  서버리스 TypeScript 함수
├─ Data API        자동 생성 REST·GraphQL API
├─ Queues          PostgreSQL 기반 작업 큐
├─ Cron            정기 작업 스케줄러
└─ AI & Vectors    pgvector 기반 벡터 검색

모든 기능을 한꺼번에 도입할 필요는 없습니다. PostgreSQL만 먼저 이전한 뒤 Realtime, Queues, Storage를 단계적으로 적용할 수도 있습니다. 기존 인증이나 파일 저장소를 유지하면서 필요한 기능만 선택하는 방식도 가능합니다.

Database는 플랫폼의 중심입니다

Supabase 프로젝트마다 전용 PostgreSQL 데이터베이스가 제공됩니다. 일반 PostgreSQL처럼 SQL, 인덱스, 트랜잭션, 뷰, 함수와 다양한 확장 기능을 사용할 수 있습니다.

프론트엔드가 데이터에 직접 접근하는 구조에서는 Row Level Security, 즉 RLS가 중요한 역할을 합니다. 같은 테이블이라도 로그인한 사용자와 역할에 따라 읽고 수정할 수 있는 행을 제한할 수 있습니다.

기존 서버 애플리케이션도 Prisma, Drizzle과 같은 ORM을 통해 PostgreSQL에 연결할 수 있습니다. Vercel처럼 요청마다 실행 환경이 달라지는 서버리스에서는 연결 수가 빠르게 늘 수 있으므로 Supabase가 제공하는 Supavisor의 transaction mode를 사용하는 편이 적합합니다. 반면 마이그레이션, 백업, 관리 도구는 direct connection을 구분해서 사용해야 합니다.

• 서비스 런타임: Supavisor transaction mode
• 마이그레이션과 pg_dump: direct connection
• 장시간 실행하는 백엔드: direct connection 또는 session mode

자세한 연결 방식은 Supabase 데이터베이스 연결 가이드에서 확인할 수 있습니다.

Auth는 사용자 인증과 RLS를 연결합니다

Supabase Auth는 이메일과 비밀번호, OTP, Magic Link, 소셜 로그인, JWT 발급과 사용자 관리를 제공합니다. 인증 정보는 같은 프로젝트의 PostgreSQL auth 스키마에서 관리됩니다.

Auth의 장점은 로그인 기능 자체보다 데이터베이스 권한과 자연스럽게 연결된다는 점입니다. 사용자의 JWT 정보를 RLS 정책에서 사용하면 별도의 권한 확인 API를 거치지 않고도 사용자별 데이터 접근 범위를 제한할 수 있습니다.

이미 다른 인증 서비스를 안정적으로 사용하고 있다면 데이터베이스 이전과 동시에 Auth까지 변경할 필요는 없습니다. 인증 이전은 토큰 체계와 사용자 식별자, 모바일 로그인 흐름에 영향을 주기 때문에 별도 단계로 다루는 편이 안전합니다.

자세한 구조는 Supabase Auth 아키텍처에서 확인할 수 있습니다.

Storage는 파일 저장과 전달을 담당합니다

Supabase Storage는 이미지, 영상, 문서와 같은 객체를 저장하고 전달하는 서비스입니다. S3 호환 API, CDN, 재개 가능한 업로드, 서명 URL과 RLS 기반 접근 제어를 제공합니다.

대표적인 사용 사례는 다음과 같습니다.

• 사용자 프로필과 게시물 이미지
• 공개 다운로드 파일
• 권한이 필요한 비공개 문서
• 대용량 영상과 재개 가능한 업로드
• CDN을 통한 정적 자산 전달

이미지 리사이즈와 포맷 최적화도 제공하므로, 여러 크기의 파생 이미지를 별도 워커에서 미리 생성하던 구조를 단순화할 수 있습니다. 다만 이미지 변환 기능의 요금제와 사용량은 이전 전에 확인해야 합니다.

자세한 기능은 Supabase Storage와 이미지 변환 가이드에서 확인할 수 있습니다.

Realtime은 별도 WebSocket 서버의 역할을 줄여줍니다

Supabase Realtime은 세 가지 주요 기능을 제공합니다.

• Broadcast: 채팅, 알림, 진행 상태와 같은 이벤트를 채널로 전달합니다.
• Presence: 채널에 접속한 사용자의 상태를 공유합니다.
• Postgres Changes: 테이블의 변경 사항을 구독합니다.

메시지의 정본은 PostgreSQL에 저장하고 Realtime은 즉시 전달 신호로만 사용하는 구성이 안정적입니다. 실시간 연결이 잠시 끊겨도 다시 데이터베이스를 조회해 상태를 복구할 수 있기 때문입니다.

기존에 Redis Pub/Sub과 별도 WebSocket 게이트웨이를 운영하고 있다면 Broadcast와 Presence를 이용해 유지해야 할 프로세스 수를 줄일 수 있습니다. 자세한 내용은 Supabase Realtime에서 확인할 수 있습니다.

Edge Functions는 작은 백엔드 작업에 적합합니다

Supabase Edge Functions는 Deno 기반 TypeScript 서버리스 함수입니다. 데이터베이스나 Storage와 가까운 위치에서 다음과 같은 작업을 실행할 수 있습니다.

• 외부 서비스 Webhook 처리
• 이메일과 알림 발송
• 결제 서비스 연동
• 작은 이미지 처리
• 외부 AI API 호출
• Queue 메시지 소비
• Cron이 호출하는 정기 작업

Edge Functions는 짧고 멱등적인 작업에 적합합니다. CPU 사용량이 크거나 실행 시간이 긴 이미지 변환, 대규모 배치, 장시간 AI 추론은 별도 실행 환경으로 분리하는 편이 안전합니다. Supabase Edge Functions에서도 무거운 장시간 작업은 백그라운드 워커로 분리할 것을 안내합니다.

Data API는 데이터베이스에서 자동으로 만들어집니다

Supabase는 PostgreSQL 스키마를 기반으로 REST와 GraphQL API를 자동 생성합니다. JavaScript, Flutter, Swift, Kotlin을 비롯한 클라이언트 SDK를 이용해 이러한 API를 호출할 수 있습니다.

RLS를 올바르게 설정하면 웹이나 모바일 애플리케이션이 제한된 범위에서 Data API를 직접 사용할 수 있습니다. 반면 복잡한 비즈니스 규칙이나 여러 테이블을 하나의 트랜잭션으로 변경하는 작업은 기존 백엔드 API 또는 데이터베이스 함수에 두는 편이 명확합니다.

GraphQL 기능은 Supabase GraphQL에서 확인할 수 있습니다.

Queues는 내구성이 필요한 백그라운드 작업을 보관합니다

Supabase Queues는 PostgreSQL의 pgmq 확장을 기반으로 하는 pull 방식의 작업 큐입니다. 소비자가 메시지를 가져가서 처리한 뒤 성공한 메시지를 삭제하거나 보관합니다.

메시지를 읽으면 visibility window 동안 다른 소비자에게 보이지 않습니다. 처리가 실패해 삭제하지 못하면 시간이 지난 뒤 다시 읽을 수 있습니다. 이 구조는 Redis Set에서 작업을 꺼내는 즉시 삭제하는 방식보다 재시도와 장애 복구에 유리합니다.

다음과 같은 작업에 잘 맞습니다.

• 콘텐츠 번역
• 이미지 파생본 생성
• 이메일과 푸시 발송
• 외부 API 동기화
• 대량 데이터 후처리

Queue는 작업을 저장하지만 실제 코드를 실행하지는 않습니다. Supabase Cron, Edge Functions, Vercel Functions 또는 별도 워커가 메시지를 가져가 처리해야 합니다. 자세한 내용은 Supabase Queues에서 확인할 수 있습니다.

Cron은 초 단위 정기 작업도 구성할 수 있습니다

Supabase Cron은 PostgreSQL의 pg_cron 확장을 기반으로 합니다. SQL과 데이터베이스 함수를 직접 실행하거나 Edge Function과 외부 HTTP API를 호출할 수 있습니다.

예를 들면 다음처럼 역할을 나눌 수 있습니다.

• 수십 초 간격: Queue 소비 함수 호출
• 1분 간격: 임시 조회수 합산
• 5분 간격: 만료된 게시물 상태 갱신
• 매일: 보존 기간이 지난 데이터 정리

초 단위 실행을 지원하지만 짧은 주기의 작업이 겹치지 않도록 실행 잠금과 멱등성을 설계해야 합니다. Supabase는 동시에 실행하는 작업 수와 개별 작업 시간을 제한해서 운영할 것을 권장합니다. 자세한 내용은 Supabase Cron에서 확인할 수 있습니다.

Database Webhooks는 변경 이벤트를 외부로 전달합니다

Database Webhooks는 테이블의 INSERT, UPDATE, DELETE 이후 외부 HTTP 엔드포인트를 호출합니다. 내부적으로 비동기 네트워크 확장인 pg_net을 사용하므로 데이터베이스 변경을 오래 막지 않고 이벤트를 전달할 수 있습니다.

예를 들어 파일 메타데이터가 등록됐을 때 이미지 처리 API를 호출하거나, 주문 상태가 변경됐을 때 외부 알림 시스템으로 이벤트를 보낼 수 있습니다.

다만 Webhook 호출 자체와 실제 작업 완료는 다른 문제입니다. 반드시 처리돼야 하는 작업은 Queue에 메시지를 기록하고 소비자가 재시도할 수 있게 만드는 편이 안전합니다. Supabase Database Webhooks

AI와 Vector 검색도 PostgreSQL 안에서 시작할 수 있습니다

Supabase는 pgvector 확장을 이용해 임베딩을 PostgreSQL에 저장하고 유사도 검색을 실행할 수 있습니다. 서비스의 기존 데이터와 벡터를 같은 트랜잭션과 권한 체계에서 관리할 수 있다는 장점이 있습니다.

문서 검색, 의미 기반 검색, 추천, RAG처럼 초기 규모의 AI 기능이라면 별도 벡터 데이터베이스 없이 시작할 수 있습니다. 데이터와 요청량이 크게 늘거나 벡터 검색만 독립적으로 확장해야 할 때 전문 벡터 서비스를 비교하면 됩니다.

자세한 내용은 Supabase AI & Vectors에서 확인할 수 있습니다.

운영 기능도 함께 살펴봐야 합니다

관리형 데이터베이스를 선택할 때는 API 기능뿐 아니라 복구와 관측 기능도 확인해야 합니다.

• 자동 백업과 Point-in-Time Recovery
• 연결 수와 쿼리 성능 관측
• 프로젝트 로그
• 데이터베이스 브랜칭
• 마이그레이션과 CLI

특히 데이터베이스 백업에는 Storage 객체가 포함되지 않습니다. 데이터베이스 메타데이터를 복구하더라도 같은 시점의 실제 파일이 자동으로 복원되는 것은 아니므로 파일 백업 정책을 별도로 준비해야 합니다. 자세한 내용은 Supabase Database Backups에서 확인할 수 있습니다.

Supabase와 Upstash는 어디에서 겹칠까요

Supabase와 Upstash는 모두 서버리스 환경을 겨냥하지만 출발점이 다릅니다. Supabase는 PostgreSQL을 중심으로 백엔드 기능을 묶고, Upstash는 Redis와 메시징, 검색처럼 요청 기반으로 확장하기 좋은 기능을 제공합니다.

영역	Supabase	Upstash	관계
정본 데이터	PostgreSQL Database	Redis	대체보다 보완 관계입니다.
캐시·레이트리밋	전용 Redis 기능 없음	Upstash Redis	Upstash가 명확히 담당하기 좋습니다.
실시간 통신	Realtime의 Broadcast·Presence·Postgres Changes	Upstash Realtime의 Redis Streams·SSE	기능이 겹치므로 하나를 선택할 수 있습니다.
작업 큐	Supabase Queues	QStash	pull과 push 방식의 차이가 있습니다.
정기 실행	Supabase Cron	QStash Schedules	일정 실행과 HTTP 호출 영역이 겹칩니다.
서버리스 로직	Edge Functions	QStash·Workflow	실제 함수 실행과 워크플로 조정이라는 차이가 있습니다.
벡터 검색	PostgreSQL pgvector	Upstash Vector	통합형과 전문형의 차이가 있습니다.
검색	PostgreSQL 전문 검색·Vector	Upstash Search	규모와 운영 방식에 따라 선택합니다.

PostgreSQL과 Upstash Redis는 서로 대체하지 않습니다

PostgreSQL은 사용자, 주문, 게시물, 결제처럼 정합성과 관계가 중요한 데이터의 정본에 적합합니다. Redis는 짧은 TTL 캐시, 레이트리밋, 임시 카운터와 중복 방지처럼 빠르게 읽고 사라져도 복구 가능한 데이터에 적합합니다.

따라서 Vercel 기반 서비스에서는 다음 조합이 자연스럽습니다.

Vercel 애플리케이션
├─ Supabase PostgreSQL  정본 데이터
├─ Supabase Realtime    실시간 통신
├─ Supabase Queues      내구성 있는 작업
├─ Supabase Cron        정기 실행
└─ Upstash Redis        캐시·레이트리밋·임시 카운터

Upstash Redis는 HTTPS REST API를 제공해 연결을 오래 유지하기 어려운 서버리스 환경에서 사용하기 편리합니다. 지원 명령과 연결 방식은 Upstash Redis 호환성과 REST API 가이드에서 확인할 수 있습니다.

Supabase Realtime과 Upstash Realtime은 선택 영역입니다

Supabase Realtime은 PostgreSQL 변경 구독과 Presence가 중요할 때 자연스럽습니다. Upstash Realtime은 Redis Streams와 SSE를 기반으로 이벤트 이력과 서버리스 친화적인 구독을 구성할 때 사용할 수 있습니다.

이미 데이터 정본과 권한을 Supabase에 두고 있다면 Supabase Realtime으로 통합하는 편이 단순합니다. 반대로 PostgreSQL 변경 구독이 필요 없고 Upstash Redis를 중심으로 이벤트를 관리하려면 Upstash Realtime을 검토할 수 있습니다.

Supabase Queues와 QStash는 전달 방식이 다릅니다

Supabase Queues는 소비자가 메시지를 가져가는 pull 방식입니다. Queue에 메시지를 보관하고 Cron이나 워커가 일정한 주기로 읽어 처리합니다.

QStash는 목적지 HTTP 엔드포인트로 메시지를 전달하는 push 방식입니다. 대상 API가 실패하면 재시도하고 지연 전달, 스케줄, Dead Letter Queue와 흐름 제어를 적용할 수 있습니다.

Supabase Queues
작업 저장 → 소비자가 가져감 → 처리 성공 후 삭제

QStash
작업 발행 → QStash가 API 호출 → 실패 시 재전달

Supabase 안에서 작업 상태와 이력을 관리하고 서비스 수를 줄이려면 Supabase Queues가 적합합니다. Vercel Function이나 외부 API를 즉시 호출하고 전달 재시도를 맡기려면 QStash가 편리합니다. 같은 작업을 두 큐에 중복으로 넣기보다는 처리 모델에 맞춰 하나를 선택하는 편이 좋습니다.

Supabase Cron과 QStash Schedules도 일부 겹칩니다

Supabase Cron은 SQL, 데이터베이스 함수, Edge Function과 HTTP API를 정기적으로 실행합니다. QStash Schedules는 지정한 시간에 메시지를 HTTP 목적지로 전달합니다.

데이터베이스 내부 정리나 Queue 소비처럼 Supabase와 가까운 작업은 Supabase Cron이 자연스럽습니다. 여러 외부 엔드포인트 호출과 재시도 정책이 핵심이라면 QStash Schedules가 더 편할 수 있습니다.

pgvector와 Upstash Vector는 규모와 결합도가 다릅니다

Supabase의 pgvector는 관계형 데이터와 벡터를 함께 관리합니다. RLS, 조인, 트랜잭션을 그대로 활용할 수 있어 AI 검색을 처음 도입할 때 유리합니다.

Upstash Vector는 벡터 검색에 특화된 별도 서버리스 데이터베이스입니다. 벡터 인덱스를 독립적으로 확장하거나 전문 검색 성능이 중요할 때 비교할 수 있습니다. 키워드와 의미 검색을 결합한 독립 검색 서비스가 필요하면 Upstash Search도 선택지입니다.

어떤 조합으로 시작하면 좋을까요

서비스 수를 최소화하고 PostgreSQL 중심으로 운영하려면 다음 구성이 단순합니다.

Supabase Database + Realtime + Queues + Cron

캐시와 짧은 주기의 레이트리밋이 필요하면 Upstash Redis만 추가할 수 있습니다.

Supabase Database + Realtime + Queues + Cron
+ Upstash Redis

작업을 HTTP 엔드포인트로 즉시 전달하고 재시도와 흐름 제어까지 맡기고 싶다면 Supabase Queues 대신 QStash를 선택할 수 있습니다.

Supabase Database + Realtime
+ Upstash Redis + QStash

중요한 것은 한 공급자의 기능을 모두 사용하는 것이 아니라 데이터의 성격에 맞는 정본과 실행 모델을 정하는 것입니다. 정본 데이터, 일시적 상태, 실시간 신호, 내구성 있는 작업을 구분하면 필요한 서비스도 자연스럽게 정리됩니다.

듀오랩스가 보는 관점

Supabase의 장점은 PostgreSQL 하나를 관리형 서비스로 제공하는 데 그치지 않습니다. 인증, 파일, 실시간 통신, 작업 큐와 스케줄러가 같은 데이터 모델과 권한 체계 주변에 모여 있어 작은 팀이 관리해야 할 인프라의 수를 줄여줍니다.

그렇다고 모든 역할을 Supabase에 몰아야 하는 것은 아닙니다. 캐시와 레이트리밋처럼 Redis가 분명히 잘하는 영역은 Upstash를 함께 사용하는 편이 단순할 수 있습니다. 반대로 Realtime, Queue, Cron처럼 두 플랫폼의 기능이 겹치는 영역은 운영 복잡도를 줄이기 위해 하나를 선택하는 것이 좋습니다.

듀오랩스는 서버리스 이전을 단순한 배포 위치 변경이 아니라 데이터의 정본, 이벤트 전달, 백그라운드 실행 방식을 다시 구분하는 과정으로 봅니다. 이 경계를 먼저 정리하면 Supabase와 Upstash를 경쟁 제품으로만 보지 않고 각자 잘하는 역할에 배치할 수 있습니다.