Supabase와 Neon 비교: 같은 PostgreSQL, 다른 역사와 구조

데이터베이스2026년 8월 15일글: 홍서진, Duolabs12분 읽기blog model-openai-gpt-5 neon postgresql supabase technical-note

Supabase와 Neon을 처음 보면 둘 다 관리형 PostgreSQL 서비스처럼 보입니다. 실제로 두 서비스 모두 표준 PostgreSQL 연결 방식과 SQL 생태계를 활용합니다. 그래서 기능표만 훑으면 가격과 무료 용량 정도만 비교하게 됩니다.

저도 처음에는 둘을 같은 범주에 놓고 보았습니다. 공식 문서를 나란히 읽고 나서야 비교 기준이 잘못됐다는 것을 알았습니다. Supabase는 PostgreSQL을 중심에 둔 백엔드 플랫폼에서 출발했고, Neon은 PostgreSQL의 저장소 구조를 클라우드에 맞게 다시 설계하는 데서 출발했습니다. 같은 데이터베이스를 제공하지만 해결하려는 문제의 시작점이 다릅니다.

두 서비스의 출발점은 달랐습니다

Supabase는 2020년 1월 작업을 시작했습니다. 초기 표현은 명확했습니다. 오픈소스 Firebase 대안을 만들되, 데이터 계층에는 NoSQL이 아니라 PostgreSQL을 사용한다는 방향이었습니다. 2020년 알파 기간을 거쳐 Auth와 API를 다듬었고, 2021년에는 Storage, CLI, 연결 풀링 같은 기능을 추가하며 백엔드 플랫폼의 형태를 갖췄습니다.

Neon의 출발은 데이터베이스 내부에 더 가까웠습니다. 2021년 무렵 Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich가 스토리지와 컴퓨트를 분리한 PostgreSQL을 만들기 시작했습니다. 2022년 2월 제한된 프리뷰, 같은 해 6월 기술 프리뷰를 거쳤고 12월에는 초대 전용 제한을 없앴습니다. 2024년 4월 정식 출시 단계인 GA에 도달했습니다.

시기	Supabase	Neon
2020년	PostgreSQL 기반 오픈소스 Firebase 대안으로 시작	아직 공개 전
2021년	Auth, Storage, API, CLI를 포함한 플랫폼 확장	스토리지와 컴퓨트 분리 구조 개발
2022년	PostgreSQL 개발 플랫폼으로 성장	기술 프리뷰 공개, 연말 공개 가입 전환
2024년	OrioleDB 팀 합류, 차세대 스토리지 연구 확대	4월 GA, 서버리스 PostgreSQL 정식 운영 단계 진입
2025년	OrioleDB를 포함한 PostgreSQL 기반 기술 투자 지속	Databricks 인수 발표, 데이터·AI 플랫폼과 결합 시작
2026년	Multigres 공개, 대규모 PostgreSQL 운영 기술 확대	Object Storage와 Functions 등 백엔드 기능 베타 공개

이 역사를 알고 보면 현재 제품 구성이 자연스럽게 이해됩니다. Supabase의 질문은 "앱 백엔드를 PostgreSQL 중심으로 얼마나 쉽게 조립할 수 있는가"에 가깝습니다. Neon의 질문은 "PostgreSQL 데이터베이스를 얼마나 빠르게 만들고, 복제하고, 쉬게 할 수 있는가"에 가깝습니다.

Supabase는 데이터베이스를 포함한 백엔드 플랫폼입니다

Supabase 프로젝트를 만들면 완전한 PostgreSQL 데이터베이스와 함께 Auth, Storage, Realtime, Edge Functions, 자동 생성 Data API와 관리 화면을 사용할 수 있습니다. 이 서비스들은 별개의 부가 기능처럼 보이지만 하나의 PostgreSQL 인스턴스를 중심으로 연결됩니다.

대표적인 예가 인증과 권한입니다. Supabase Auth가 발급한 JWT의 정보를 PostgreSQL Row Level Security 정책과 연결할 수 있습니다. 파일 Storage의 메타데이터와 Realtime 변경 스트림도 PostgreSQL을 중심으로 동작합니다. 프론트엔드 개발자가 데이터베이스, 인증 서버, 파일 저장소와 실시간 이벤트 서버를 각각 선정하고 연결해야 하는 작업을 한 플랫폼 안에서 시작할 수 있습니다.

현재 Supabase의 기본 데이터베이스 구조는 프로젝트별 전용 PostgreSQL 인스턴스와 SSD 디스크입니다. 컴퓨트 크기를 정하고 필요할 때 상향하거나 하향합니다. 디스크 처리량과 IOPS도 컴퓨트와 디스크 설정의 영향을 받습니다. 크기 변경에 재시작과 중단 시간이 생길 수 있다는 점까지 전통적인 관리형 데이터베이스의 성격이 남아 있습니다.

연결 방식은 용도에 따라 나뉩니다. 마이그레이션과 pg_dump에는 직접 연결을 쓰고, 서버리스 함수처럼 연결이 자주 생겼다가 사라지는 환경에는 Supavisor 트랜잭션 풀링을 사용할 수 있습니다. 애플리케이션 계층을 넓게 제공하면서도 데이터베이스 자체는 PostgreSQL로 직접 접근할 수 있다는 점이 Supabase의 중요한 특징입니다.

Neon은 데이터베이스의 수명 주기를 다시 설계했습니다

Neon도 애플리케이션에서 보면 PostgreSQL입니다. 차이는 그 아래에 있습니다. PostgreSQL이 실행되는 컴퓨트와 데이터가 보관되는 스토리지를 분리합니다. 컴퓨트는 SQL 실행과 트랜잭션을 담당하고, 데이터 페이지는 Neon이 만든 분산 스토리지 계층에 보관됩니다.

최근 변경 사항은 먼저 Safekeeper에 기록되고, Pageserver가 WAL을 데이터 페이지 형태로 처리해 객체 스토리지에 올립니다. 컴퓨트가 중지돼도 데이터는 별도 스토리지에 남습니다. 이 구조 덕분에 컴퓨트만 부하에 맞춰 조절하거나, 사용하지 않을 때 0까지 줄였다가 연결 요청이 오면 다시 시작할 수 있습니다.

대신 첫 연결에는 컴퓨트가 깨어나는 시간이 추가될 수 있습니다. Neon은 이 시간을 줄여 왔지만, 지연에 매우 민감한 상시 트래픽이라면 최소 컴퓨트를 유지하는 설정과 연결 재시도 전략을 함께 봐야 합니다. 서버리스라는 이름이 지연까지 사라진다는 뜻은 아닙니다.

Branching이라는 같은 단어도 의미가 다릅니다

두 서비스 모두 Branching을 제공하지만 복사하는 대상이 다릅니다.

Neon Branch는 부모 데이터베이스의 스키마와 데이터를 특정 시점에서 이어받습니다. 전체 데이터를 물리적으로 다시 복사하지 않고 Copy-on-Write 방식으로 공통 기반을 공유하며 변경분만 추가합니다. 데이터베이스 크기와 무관하게 빠르게 분기할 수 있고, 각 Branch는 독립된 연결 문자열과 컴퓨트를 가집니다. 운영 데이터가 포함되면 편리한 만큼 개인정보 마스킹과 접근 통제가 필요합니다. 민감한 데이터가 있다면 Schema-only Branch를 선택할 수 있습니다.

Supabase Branch는 데이터베이스만이 아니라 API 키와 관련 서비스까지 포함한 별도 Supabase 환경에 가깝습니다. 현재 기본 새 Branch는 운영 데이터를 복사하지 않는 Data-less 방식입니다. 스키마 마이그레이션과 Seed 파일을 통해 재현 가능한 프리뷰 환경을 만드는 데 초점을 둡니다.

따라서 "Branching을 지원한다"만으로 두 기능을 같다고 보면 안 됩니다. 운영 데이터의 특정 시점을 빠르게 복제해 테스트하려면 Neon 방식이 직접적입니다. 데이터 노출을 줄이고 전체 백엔드 구성을 Pull Request 단위로 검증하려면 Supabase의 Data-less 환경이 더 자연스러울 수 있습니다.

비교표보다 먼저 정해야 할 질문

비교 기준	Supabase	Neon
제품의 중심	PostgreSQL 기반 백엔드 플랫폼	서버리스 PostgreSQL 플랫폼
기본 컴퓨트 구조	프로젝트별 전용 인스턴스와 디스크	컴퓨트와 분산 스토리지 분리
유휴 상태	인스턴스 중심 운영	컴퓨트 Scale to Zero 지원
데이터베이스 분기	별도 Supabase 환경, 기본 Data-less	스키마와 데이터를 Copy-on-Write로 분기
앱 기능	Auth, Storage, Realtime, Functions, Data API 포함	역사적으로 DB 중심, 2026년부터 백엔드 기능을 베타로 확대
잘 맞는 시작점	앱 백엔드를 한 플랫폼에서 구성	DB 생성과 분기를 자동화하고 컴퓨트 비용을 사용량에 맞춤

로그인, 파일 업로드, 권한 정책, 실시간 구독까지 한 번에 필요하다면 Supabase부터 검토하는 편이 빠릅니다. 특히 클라이언트가 Data API를 직접 사용하고 RLS로 권한을 통제하는 구조와 잘 맞습니다.

이미 인증과 파일 저장, 함수 실행 환경이 따로 있고 PostgreSQL만 유연하게 운영하려면 Neon의 장점이 분명해집니다. Pull Request마다 실제 데이터 상태를 가진 데이터베이스를 만들거나, 고객 또는 AI 에이전트마다 짧게 쓰는 데이터베이스를 자동 생성하는 구조에도 적합합니다.

항상 켜진 일정한 부하에서는 Neon의 Scale to Zero가 큰 의미가 없을 수 있습니다. 반대로 개발, 테스트와 간헐적 서비스처럼 유휴 시간이 긴 환경에서는 전용 인스턴스를 계속 유지하는 비용이 아깝습니다. 제품 이름보다 트래픽의 모양을 먼저 봐야 합니다.

두 서비스는 서로의 영역으로 이동하고 있습니다

두 제품의 차이는 선명하지만 고정된 것은 아닙니다. Supabase는 2024년 OrioleDB 팀을 영입해 PostgreSQL 스토리지 엔진과 스토리지·컴퓨트 분리를 연구하기 시작했습니다. 이후 Multigres 같은 프로젝트에도 투자하며 대규모 PostgreSQL 운영 문제를 다루고 있습니다.

Neon은 2025년 Databricks 인수 계획을 발표했고, 2026년에는 Object Storage, Functions, AI Gateway와 관리형 인증을 포함한 백엔드 기능을 베타로 공개했습니다. 다만 이 기능들은 아직 지역과 완성도에 제한이 있으므로 Supabase의 성숙한 백엔드 제품군과 바로 같은 단계로 보기는 어렵습니다.

앞으로 기능 목록은 더 비슷해질 가능성이 큽니다. 그래도 출발점은 제품의 우선순위에 오래 남습니다. Supabase는 앱을 완성하는 데 필요한 통합 경험을 먼저 다듬어 왔고, Neon은 데이터베이스 생성, 분기와 컴퓨트 효율을 먼저 다듬어 왔습니다.

제가 두 서비스를 고른다면 "PostgreSQL이 필요한가"에서 멈추지 않고 한 가지를 더 묻겠습니다. 지금 해결하려는 문제가 앱 백엔드의 조립인지, 데이터베이스 수명 주기의 자동화인지입니다. 이 질문에 답하면 선택지는 꽤 빠르게 좁혀집니다.