Supabase·Neon 비교: 사용자 도메인, IPv4, DB 브랜치는 언제 필요할까?

고객사 명의로 Supabase Pro 프로젝트를 하나 만들고 운영 DB를 옮겼습니다. 요금표를 읽다 보니 용량 말고도 Pro에서만 켤 수 있는 항목이 몇 개 보였습니다. 사용자 도메인, IPv4 직결, 브랜치입니다. 이름만 보면 다 있으면 좋을 것 같아서 다른 관리형 Postgres(Neon, PlanetScale, AWS RDS·Aurora, Railway)와 Firebase에서는 같은 것이 어떻게 생겼는지 같이 찾아봤습니다. 세 기능 모두 서비스마다 모양이 꽤 달랐고, 결론부터 말하면 이 프로젝트에는 셋 다 필요하지 않았습니다. 왜 필요 없었는지가 곧 누구에게 필요한지의 답이라 정리해 둡니다.

같은 Postgres, 다른 운영 조건

먼저 확인한 것은 무료와 유료의 기능 차이입니다. Supabase 기준으로 Postgres 버전, 확장, 풀러는 무료와 Pro가 같습니다. 이 앱은 Next.js 서버가 Prisma로 Postgres에 붙는 것이 전부라서, 앱 코드 입장에서는 둘을 구분할 방법이 없습니다.

차이는 운영 쪽에 있습니다. Supabase 무료는 7일 동안 요청이 없으면 프로젝트가 멈추고, 사용자가 받아서 되살릴 수 있는 백업이 없습니다. 운영 DB를 Pro로 둔 이유는 이 두 가지였습니다. 아래 세 기능은 Supabase에서는 Pro 이상에서만 켤 수 있는 유료 추가 기능이고, 다른 서비스에서는 기본으로 주거나 아예 없거나 전혀 다른 방식으로 있습니다.

IPv4: Supabase만 따로 돈을 받는 이유

서비스	외부에서 IPv4로 붙기
Supabase	직결은 IPv6만. 풀러는 IPv4 무료. 직결 IPv4는 Pro에서 추가 기능
Neon	AWS 리전 프로젝트는 IPv4와 IPv6 모두 기본
Railway	DB는 기본 비공개. 공개하면 TCP 프록시 주소가 생기고 전송량만 과금
AWS RDS	공인 IPv4를 달면 2024년 2월부터 시간당 $0.005

Supabase는 붙는 길이 셋입니다. 직결(5432), 세션 풀러(5432), 트랜잭션 풀러(6543)입니다. 이 중 직결 주소는 AAAA 레코드만 가지고 있어서, IPv6가 안 되는 망에서는 DNS 단계에서 이미 갈 곳이 없습니다.

dig +short A    db.<project-ref>.supabase.co   # 비어 있음
dig +short AAAA db.<project-ref>.supabase.co   # IPv6 주소 하나

Supabase Pro에서는 IPv4 추가 기능을 켤 수 있습니다. 시간당 $0.0055, 한 달에 약 $4입니다. AWS가 공인 IPv4 하나에 받는 $0.005와 거의 같은 숫자라서, AWS 위에서 도는 서비스가 그 비용을 기본값에서 빼고 추가 기능으로 돌린 것으로 읽었습니다. 문서를 읽다 하나 놀란 점이 있습니다. 이 기능은 IPv4를 더하는 것이 아니라 IPv6 레코드를 IPv4로 바꿉니다. 켜고 나면 IPv6로 붙던 쪽이 끊깁니다.

저는 이 돈을 내지 않았습니다. 처음부터 직결을 쓰지 않고 풀러 두 개로만 붙게 해 두었기 때문입니다. 앱은 트랜잭션 풀러로 붙고, 서버리스 함수는 인스턴스가 여럿 뜨니 인스턴스마다 연결 수를 작게 묶었습니다.

// src/lib/prisma.ts
import { PrismaPg } from "@prisma/adapter-pg";

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL!, max: 3 });

마이그레이션은 세션 풀러로 보냅니다. 트랜잭션 풀러는 요청마다 다른 백엔드 연결을 줄 수 있어서, 세션에 기대는 마이그레이션이 그 위에서 깨질 수 있습니다.

// prisma.config.ts
export default defineConfig({
  schema: "prisma/schema.prisma",
  datasource: {
    // 운영: DIRECT_URL = 세션 풀러(5432). 로컬 postgres 는 풀러가 없어 비워 두면 DATABASE_URL 하나로 돈다
    url: process.env["DIRECT_URL"] || process.env["DATABASE_URL"],
  },
});

# 값의 모양만. 실제 값은 볼트에 있습니다
DATABASE_URL=postgresql://postgres.<ref>:<password>@<pooler-host>:6543/postgres
DIRECT_URL=postgresql://postgres.<ref>:<password>@<pooler-host>:5432/postgres

Neon이나 Railway를 쓰면 이 고민 자체가 없습니다. Supabase에서 IPv4 추가 기능이 필요한 쪽은 풀러가 해결해 주지 못하는 일을 하는 서비스입니다. 연결을 오래 붙들고 LISTEN/NOTIFY를 받는 워커, 논리 복제로 다른 시스템에 변경을 흘려보내는 파이프라인, IPv6가 없는 사내망에서 직접 붙어야 하는 BI 도구 같은 경우입니다.

사용자 도메인: DB가 아니라 백엔드를 빌릴 때의 문제

서비스	사용자 도메인
Supabase	Auth·API·Storage 주소를 회사 도메인으로. Pro에서 추가 기능, 프로젝트당 월 $10
Firebase	Hosting에 붙인 도메인을 Auth의 authDomain으로 씀
Neon, RDS, Railway	DB 접속 주소뿐이라 해당 없음

Supabase의 사용자 도메인은 <ref>.supabase.co 대신 api.example.com 같은 회사 도메인을 붙이는 기능입니다. Postgres 접속 주소를 바꾸는 기능이 아니라는 점이 핵심입니다. 바뀌는 것은 Supabase가 HTTP로 내놓는 면, 그러니까 Auth, REST·GraphQL API, Storage, Edge Functions의 주소입니다.

Firebase도 같은 문제를 같은 자리에서 풉니다. 구글 로그인을 리다이렉트로 붙이면 브라우저가 authDomain으로 갔다가 돌아오는데, 기본값은 <project>.firebaseapp.com입니다. 앱 도메인과 다르면 서드파티 저장소를 막는 브라우저에서 로그인이 깨질 수 있어서, Firebase 문서는 Hosting에 붙인 회사 도메인을 authDomain으로 쓰라고 권합니다.

// Firebase: 로그인 도우미를 앱과 같은 도메인에서 띄운다
initializeApp({
  apiKey: "...",
  authDomain: "app.example.com", // 기본값 <project>.firebaseapp.com 대신
});

Neon, RDS, Railway 같은 순수 DB 서비스에는 이 기능이 없습니다. 브라우저가 직접 부를 HTTP 면이 없으니 바꿀 주소도 없습니다. 그래서 이 항목은 DB 비교가 아니라 「백엔드 전체를 빌려 쓰느냐」의 문제입니다. 로그인 동의 화면이나 네트워크 탭에 낯선 도메인이 보이는 것이 고객 신뢰와 닿는 서비스라면 낼 만한 돈입니다.

이 앱은 반대 경우입니다. 사용자 브라우저는 Next.js 서버만 보고, DB 주소는 서버 환경변수 안에만 있습니다. 로그인도 Supabase Auth를 쓰지 않습니다. 사용자 눈에 띌 Supabase 주소가 어디에도 없습니다.

브랜치: 데이터를 가져오느냐로 갈리는 기능

세 가지 중 서비스마다 가장 다르게 생긴 것이 브랜치입니다. git 브랜치처럼 DB를 하나 더 띄워서 운영과 떨어진 곳에서 마이그레이션을 돌려 보는 기능인데, 처음에 데이터가 들어 있느냐가 서비스마다 다릅니다.

서비스	만드는 법	처음 데이터	비용
Supabase	GitHub 연결 시 PR마다 자동	기본은 빈 DB + seed.sql. 대시보드에서는 데이터 포함 선택 가능	Pro에서, 브랜치당 시간당 $0.01344부터
Neon	CLI·API·대시보드	부모의 스키마와 데이터 그대로 (copy-on-write)	무료 요금제도 프로젝트당 10개
PlanetScale (Postgres)	대시보드·CLI	빈 브랜치, 또는 백업에서 만들면 데이터째	유료
AWS Aurora	클러스터 복제	원본 데이터 그대로 (copy-on-write, 15개까지)	복제 클러스터의 인스턴스 + 바뀐 페이지만큼 저장
AWS RDS	스냅숏 복원	스냅숏 시점 데이터 (통째 복사)	새 인스턴스 비용

처음에는 Supabase 브랜치가 운영 데이터를 전혀 가져오지 않는다고 알고 있었습니다. 문서를 다시 보니 기본값은 빈 DB가 맞지만, 대시보드에서 만들 때는 데이터를 함께 가져오는 선택지가 생겨 있었습니다. PlanetScale의 Postgres도 비슷하게 갈립니다. 브랜치 화면에서 만들면 스키마조차 없는 빈 DB이고, 백업에서 만들면 데이터가 따라옵니다. 두 서비스 모두 운영 데이터를 시험 환경에 흘리지 않는 쪽이 기본이고, 가져오는 것은 사람이 고르는 일입니다.

Neon과 Aurora 복제는 출발점이 반대입니다. 브랜치가 부모의 데이터 페이지를 가리키기만 하는 copy-on-write라서, 데이터가 몇백 GB여도 만드는 순간 운영과 같은 데이터가 들어 있습니다. Neon은 이것을 무료 요금제에서도 줍니다.

# Neon: 운영(main)에서 스키마와 데이터를 그대로 이어받은 브랜치
neon branches create --name staging --parent main
neon connection-string staging

어느 쪽이 맞는지는 무엇을 시험하느냐로 갈립니다. 마이그레이션이 실제 데이터 위에서 몇 분 걸리는지, 지난 3년치 행 중에 새 제약을 어기는 것이 있는지를 미리 보려면 데이터가 있어야 하고, 여기서는 Neon과 Aurora가 강합니다. 반대로 거래처 이름과 단가가 든 DB를 PR마다 복제하면 고객 데이터가 시험 환경 수만큼 퍼집니다. 개인정보나 영업 자료가 든 서비스라면 빈 DB가 기본인 Supabase나 PlanetScale 쪽이 사고를 덜 냅니다.

브랜치가 제값을 하는 팀은 모양이 정해져 있습니다. 여러 사람이 동시에 PR을 열고, 각 PR이 마이그레이션을 들고 오고, 미리보기 배포가 PR마다 따로 뜨는 팀입니다. 혼자 main에 바로 push하는 프로젝트에는 PR마다 DB가 생기는 구조가 얹힐 자리가 없습니다. 이 프로젝트에는 이유가 하나 더 있었습니다. Supabase 브랜치는 리포의 supabase/migrations 폴더를 읽는데, 이 앱의 마이그레이션은 prisma/migrations에 있습니다. 붙이려면 Prisma가 만든 SQL을 Supabase가 읽는 자리로 옮기는 작업을 따로 둬야 합니다.

스테이징은 무료 조직의 프로젝트 하나

브랜치를 안 쓰기로 하고 나니 스테이징을 어디에 둘지가 남았습니다. 처음에는 Pro 조직에 프로젝트를 하나 더 만들면 될 줄 알았습니다. 그런데 Supabase Pro 요금은 조직 단위이고 컴퓨트는 프로젝트마다 붙습니다. 한 달 $25에 든 컴퓨트 크레딧 $10이 첫 프로젝트를 덮고, 둘째 프로젝트부터는 가장 작은 크기로도 한 달 약 $10이 더 나갑니다. 유료 조직 안에 무료 프로젝트는 둘 수 없습니다.

그래서 같은 계정에 무료 조직을 하나 따로 만들고 거기에 스테이징을 두기로 했습니다. 무료 프로젝트 한도(활성 2개)는 조직이 아니라 계정에 걸리기 때문에, 무료 조직을 여러 개 만든다고 한도가 늘지는 않습니다. 개발은 로컬 도커의 Postgres로 하니 클라우드에는 스테이징 하나면 됩니다.

무료 스테이징의 한계는 분명합니다. 가장 작은 서버로 고정이라 속도는 운영과 비교가 안 되고, 일주일 쉬면 멈춥니다. 대신 로컬은 Postgres 18이고 Supabase는 17이라서, 18에만 있는 문법이 마이그레이션에 섞였을 때 운영에 닿기 전에 걸러 주는 곳이 생겼습니다. 스테이징에 기대하는 것은 그 정도입니다.

세 기능이 각각 필요한 서비스

기능	필요한 서비스	고를 만한 곳
IPv4 직결	오래 붙는 워커, 논리 복제, IPv6 없는 사내망에서 직접 붙는 도구	Neon·Railway는 기본. Supabase는 Pro 추가 기능
사용자 도메인	Auth·Storage를 브라우저가 직접 부르는 앱, 로그인 화면의 도메인이 신뢰와 닿는 서비스	Supabase Pro 추가 기능, Firebase authDomain
브랜치 (실데이터)	큰 테이블의 마이그레이션 시간과 데이터 충돌을 미리 봐야 하는 팀	Neon, Aurora 복제
브랜치 (빈 DB)	여러 사람이 PR마다 마이그레이션을 들고 오고, 고객 데이터를 퍼뜨리면 안 되는 팀	Supabase Pro, PlanetScale

서버만 DB에 붙고, 혼자 main에 배포하고, 풀러로 충분한 앱이라면 넷 중 어느 줄에도 해당하지 않습니다. 이 프로젝트가 그랬습니다.

요금과 한도는 2026년 10월에 각 서비스 문서에서 확인한 값입니다. 바뀔 수 있으니 결정할 때는 링크한 문서를 다시 보시길 권합니다.

참고: Supabase 요금, Neon 요금제