Neon·Supabase 대체 서비스: 2026년 비교와 추천 순위

Neon과 Supabase를 대신할 서비스를 정리해 달라는 질문을 받았습니다. 처음에는 후보를 한 표에 놓고 유명한 순서부터 매기려 했습니다. 공식 문서를 다시 읽어 보니 출발점부터 잘못되었습니다.

Neon은 서버리스 PostgreSQL이 중심인 서비스입니다. Supabase는 PostgreSQL에 인증, 스토리지, Realtime, Functions를 묶은 백엔드 플랫폼입니다. 둘을 같은 줄에 세우면 Aurora와 Appwrite가 직접 경쟁하는 것처럼 보이는 이상한 표가 됩니다.

그래서 이번에는 두 목록을 분리했습니다. 2026년 8월 17일을 기준으로 유명도와 제가 실제 프로젝트에서 우선 검토할 순서를 따로 매겼습니다. 유명도는 제품의 우열이 아닙니다. 클라우드 시장의 인지도, 개발자 생태계, 공개 커뮤니티 규모를 함께 본 대략적인 순서입니다.

Neon을 바꾼다면 무엇을 비교해야 할까

Neon의 핵심은 PostgreSQL 호환성만이 아닙니다. 사용하지 않을 때 비용을 줄이는 서버리스 구조, 연결 풀링, 데이터베이스 브랜치 같은 개발 흐름까지 한 제품에 들어 있습니다. 따라서 단순히 PostgreSQL을 제공한다는 이유만으로 같은 대안이라고 보기는 어렵습니다.

제가 후보를 볼 때 확인한 항목은 다음과 같습니다.

• 기존 드라이버와 ORM을 그대로 사용할 수 있는가
• 연결이 몰리는 서버리스 환경을 어떻게 처리하는가
• 백업, 복구, 고가용성 구성이 기본으로 제공되는가
• 개발용 데이터베이스를 분리하기 쉬운가
• 작은 서비스에서도 감당할 만한 운영 복잡도인가

유명도 순으로는 AWS Aurora/RDS, Google Cloud SQL/AlloyDB, PlanetScale, Aiven, Crunchy Bridge라고 보았습니다. AWS와 Google Cloud는 브랜드와 기업 도입 면에서 앞섭니다. PlanetScale은 MySQL과 Vitess로 먼저 알려졌고 이제 PostgreSQL 제품도 운영하고 있습니다.

하지만 작은 팀이 Neon에서 옮긴다는 조건으로 추천 순서를 매기면 결과가 달라집니다.

추천	서비스	제가 먼저 보는 이유	확인할 점
1	PlanetScale Postgres	표준 PostgreSQL 연결, PgBouncer, 관리형 HA, 개발 브랜치를 한곳에서 제공	Neon과 브랜치 동작이 같지는 않음
2	Crunchy Bridge	PostgreSQL 전문 업체가 운영하며 백업, PITR, HA 구성이 명확함	scale-to-zero형 서비스는 아님
3	Aiven for PostgreSQL	여러 클라우드와 리전 선택, 백업과 HA 옵션이 풍부함	소규모 서비스에서는 비용 확인 필요
4	Aurora Serverless v2	AWS의 VPC, IAM, 관측 도구와 함께 쓰기 좋음	구성과 비용 모델이 더 복잡함
5	AlloyDB	GCP의 고성능 PostgreSQL 워크로드와 AI 기능에 적합	가벼운 사이드 프로젝트에는 과한 선택일 수 있음

현재 제 첫 후보는 PlanetScale Postgres입니다. 표준 포트와 PgBouncer 연결을 제공하고, 프로덕션 구성에서는 복제본과 자동 장애 조치를 선택할 수 있습니다.

여기서 한 가지를 잘못 이해하기 쉬웠습니다. 제품 소개에 database branching이 있다고 해서 Neon의 브랜치와 같은 경험이라고 생각하면 안 됩니다. PlanetScale 공식 문서를 확인하면 PostgreSQL 브랜치는 빈 데이터베이스 또는 백업 복원으로 만들며, 스키마 변경을 프로덕션으로 자동 병합하는 기능은 아직 없습니다. 이 차이는 마이그레이션 전에 꼭 확인해야 합니다. PlanetScale 브랜치 문서

브랜치보다 PostgreSQL 자체의 예측 가능성이 중요하다면 Crunchy Bridge가 더 편한 답일 수 있습니다. 자동 디스크 확장, 백업, 연결 풀링, HA와 재해 복구 기능을 명시적으로 제공합니다. Aiven for PostgreSQL은 멀티클라우드와 운영 옵션이 필요할 때 검토할 만합니다.

Aurora Serverless v2와 AlloyDB는 나쁜 선택이라 순위가 낮은 것이 아닙니다. 이미 AWS 또는 GCP에 깊게 들어간 조직이라면 오히려 먼저 봐야 합니다. 여기서는 작은 웹 서비스가 Neon의 간결함을 대체한다는 조건 때문에 뒤로 두었습니다.

Supabase 대체재는 데이터베이스만 보면 안 됩니다

Supabase에서 실제로 쓰는 것이 데이터베이스뿐이라면 앞의 PostgreSQL 목록으로 충분합니다. 하지만 Auth, Storage, Realtime, Edge Functions까지 쓰고 있다면 이야기가 달라집니다. 데이터 이전보다 인증 세션, 권한 규칙, 파일 URL, 실시간 구독 코드를 다시 만드는 비용이 더 커질 수 있습니다.

유명도는 Firebase, Appwrite, PocketBase, Convex, Nhost 순으로 보았습니다. 오픈소스 저장소의 GitHub 스타만 보면 2026년 8월 확인 당시 PocketBase가 약 58.6천 개, Appwrite가 약 56.7천 개, Convex가 약 11.9천 개, Nhost가 약 9.2천 개였습니다. Firebase는 같은 방식으로 비교할 단일 오픈소스 저장소가 없으므로 Google 생태계와 시장 인지도를 기준으로 앞에 두었습니다. 스타 수는 관심도를 보여 주는 신호일 뿐, 운영 안정성이나 실제 사용자 수를 증명하지는 않습니다.

Supabase에서 이전하기 쉬운 정도를 더 중요하게 보면 제 순서는 다음과 같습니다.

추천	서비스	잘 맞는 경우	가장 큰 차이
1	Nhost	PostgreSQL과 통합 Auth, Storage를 계속 원하는 경우	REST/PostgREST보다 GraphQL과 Hasura 권한 모델 중심
2	Appwrite	완성된 BaaS와 셀프호스팅 선택지가 필요한 경우	raw PostgreSQL보다 Appwrite API에 결합
3	Convex	Next.js, React 기반 실시간 제품을 새로 만드는 경우	SQL과 ORM 대신 TypeScript 함수로 데이터 접근
4	Firebase SQL Connect	모바일 앱과 Google Cloud 생태계를 함께 쓰는 경우	관리형 GraphQL과 생성 SDK 중심, Google 종속성 증가
5	PocketBase	개인 프로젝트나 단일 서버의 작은 서비스	SQLite 기반이며 v1 이전이라 호환성 변경 가능

Nhost는 전용 PostgreSQL, 자동 생성 GraphQL API, Auth, S3 호환 Storage, Functions와 Events를 함께 제공합니다. 구성 요소만 놓고 보면 Supabase와 가장 가까웠습니다. 다만 Supabase의 PostgREST와 PostgreSQL RLS를 그대로 옮기는 제품은 아닙니다. Hasura의 GraphQL 권한 모델을 받아들일 수 있는지가 첫 번째 판단 기준입니다.

Appwrite는 Auth, Databases, Storage, Functions, Realtime, Messaging과 사이트 호스팅을 제공합니다. 관리형 클라우드와 셀프호스팅을 모두 고를 수 있고 공개 커뮤니티도 큽니다. 반대로 기존 애플리케이션이 SQL, PostgreSQL 함수, 확장 기능에 많이 의존한다면 이전 비용이 커집니다. 데이터베이스가 같으냐보다 애플리케이션이 Appwrite API 모델로 바뀐다는 점을 봐야 합니다.

Convex는 처음에는 Supabase의 직접 대체재로 넣기 애매했습니다. SQL을 쓰지 않고 쿼리와 변경 로직을 TypeScript 함수로 작성하기 때문입니다. 그러나 React 화면이 데이터 변경에 즉시 반응해야 하는 새 프로젝트라면 이 차이가 장점이 됩니다. 기존 PostgreSQL 앱을 옮기는 후보라기보다 백엔드 구조를 새로 선택할 때 강한 후보라고 판단했습니다.

Firebase에는 이제 SQL Connect가 있습니다. Cloud SQL for PostgreSQL을 기반으로 스키마와 미리 정의한 GraphQL 작업에서 타입 안전 SDK를 생성합니다. Firebase Auth, Functions, Storage를 이미 쓰는 모바일 팀에는 자연스럽습니다. 반면 PostgreSQL에 일반 드라이버로 직접 연결하던 서버 애플리케이션과는 개발 흐름이 다릅니다.

PocketBase는 한 실행 파일에 SQLite, Auth, 파일 관리, Realtime과 관리자 화면이 들어 있습니다. 간단함만 놓고 보면 가장 인상적인 후보였습니다. 공식 저장소는 v1.0 이전까지 완전한 하위 호환성을 보장하지 않는다고 경고합니다. 저는 개인 도구와 작은 내부 서비스에는 적극적으로 검토하겠지만, 여러 인스턴스로 수평 확장해야 하는 핵심 서비스의 첫 선택으로 두지는 않겠습니다.

결국 기능 이름보다 이전 범위가 먼저입니다

제가 실제 후보를 줄인다면 이렇게 시작하겠습니다.

현재 필요한 것	첫 후보
PostgreSQL 데이터베이스만 교체	PlanetScale Postgres
표준 PostgreSQL과 보수적인 운영	Crunchy Bridge
Supabase와 비슷한 통합형 구성	Nhost
자체 서버에 올릴 완성형 BaaS	Appwrite
React 중심의 새 실시간 앱	Convex
모바일과 Google Cloud 통합	Firebase SQL Connect
개인 프로젝트와 작은 단일 서버	PocketBase
이미 AWS에 모인 대규모 서비스	Aurora Serverless v2

처음 질문은 “어느 서비스가 가장 유명한가”였습니다. 조사한 뒤에는 질문을 하나 더 붙이는 편이 맞다고 보았습니다. 지금 사용하는 것이 PostgreSQL 연결 문자열 하나인지, 아니면 인증과 권한, 파일, 실시간 구독까지인지 먼저 확인해야 합니다.

저라면 데이터베이스만 옮길 때는 PlanetScale Postgres와 Crunchy Bridge부터 시험합니다. Supabase 전체를 바꿀 때는 Nhost를 먼저 검증하고, GraphQL 전환이 맞지 않으면 Appwrite 또는 기능별 분리를 검토합니다. 새 React 실시간 제품이라면 Convex도 별도 후보로 둡니다. 이 순서를 정한 이유는 기능표의 체크 개수가 아니라, 지금 가진 코드를 얼마나 적게 버리고도 운영 목적을 달성할 수 있는지에 있습니다.