Supabase vs Neon vs Firebase SQL Connect: 차이와 선택 기준

세 서비스를 한 문장으로 구분하기

세 제품은 모두 PostgreSQL 또는 관계형 데이터와 연결되지만 출발점이 다릅니다.

Supabase
PostgreSQL 기반 앱 백엔드 플랫폼

Neon
관리형 서버리스 PostgreSQL 플랫폼

Firebase SQL Connect
Firebase 앱과 Cloud SQL for PostgreSQL을 연결하는 관계형 데이터 서비스

Supabase는 데이터베이스 외에도 Auth, Storage, Data API, Realtime 같은 앱 기능을 함께 제공합니다.

Neon은 PostgreSQL 자체의 운영과 확장, 브랜칭 같은 데이터베이스 경험에 중심이 있습니다. 앱 인증과 API 계층은 팀이 선택한 다른 도구와 조합할 수 있습니다.

Firebase SQL Connect는 Firebase 생태계에서 관계형 데이터를 사용하도록 Cloud SQL for PostgreSQL과 GraphQL 기반 스키마·쿼리·뮤테이션, 타입 안전 SDK를 연결합니다.

따라서 “셋 중 무엇이 더 좋은가?”보다 다음 질문이 더 중요합니다.

나는 앱 백엔드 전체가 필요한가?
DB만 강하게 관리하고 싶은가?
이미 Firebase 앱이 있고 관계형 데이터가 필요한가?

Supabase의 역할

Supabase는 PostgreSQL을 중심으로 애플리케이션 백엔드에 필요한 여러 기능을 묶어 제공합니다.

대표적으로 다음 영역이 한 프로젝트 안에 있습니다.

• PostgreSQL Database
• Auth
• Storage
• 자동 생성 Data API
• Realtime
• Edge Functions
• Row Level Security

프론트엔드 앱이 publishable key로 Data API를 호출하더라도, 로그인 여부에 따라 요청은 Postgres의 anon 또는 authenticated 역할로 실행됩니다.

여기서 중요한 점은 publishable key 자체가 데이터를 보호하는 비밀키가 아니라는 것입니다.

브라우저에서 볼 수 있는 공개 키를 사용하는 대신, 실제 접근 권한은 PostgreSQL의 GRANT와 RLS 정책으로 제한해야 합니다.

즉 Supabase를 고르면 편리한 SDK만 배우는 것이 아니라 다음 책임도 함께 배워야 합니다.

누가 어떤 SQL 작업을 할 수 있는가
+
그 작업이 어떤 행에 적용될 수 있는가

이 과정에서 RLS를 중요한 학습 주제로 다루는 이유입니다.

Neon의 역할

Neon은 서버리스 PostgreSQL과 데이터베이스 브랜칭을 중심으로 제공합니다. 관리형 인증인 Managed Better Auth와 Data API도 선택할 수 있으므로, 인증이나 API를 반드시 외부에서 따로 구현해야 한다는 뜻은 아닙니다. 아래 구조는 ORM·서버 코드를 직접 조합하는 한 가지 선택입니다.

애플리케이션에서 일반적으로 다음과 같은 구조를 선택할 수 있습니다.

Next.js
↓
Server Action / Route Handler
↓
ORM 또는 PostgreSQL driver
↓
Neon PostgreSQL

이 구조에서는 인증, 파일 저장, API 설계를 개발자가 별도 서비스나 서버 코드와 조합하는 경우가 많습니다.

Neon의 장점은 데이터베이스 계층을 독립적으로 설계하고 싶은 프로젝트에서 분명합니다.

예를 들어 다음과 같은 팀이라면 자연스럽습니다.

• PostgreSQL을 직접 중심에 두고 싶은 경우
• Prisma, Drizzle 등 ORM을 직접 선택하려는 경우
• 데이터베이스 브랜칭이 중요한 경우
• 인증과 Storage를 각각 다른 서비스로 조합하려는 경우

반대로 처음부터 Auth, DB, Storage, 클라이언트 SDK를 하나의 개발 흐름으로 연결해 학습하려면 직접 결정해야 할 범위가 더 넓습니다.

Firebase SQL Connect의 역할

Firebase SQL Connect는 Firebase의 관계형 데이터 서비스입니다.

공식 문서 기준으로 Cloud SQL for PostgreSQL을 기반으로 하고, GraphQL 기술을 이용해 스키마와 쿼리·뮤테이션을 정의하며 모바일·웹용 타입 안전 SDK를 생성합니다.

구조를 단순화하면 다음과 같습니다.

Firebase 앱
↓
생성된 SDK
↓
배포된 SQL Connect Query / Mutation
↓
Cloud SQL for PostgreSQL

특히 이미 Firebase Authentication과 Firebase 프로젝트 구조를 쓰고 있다면 관계형 데이터를 추가하는 선택지가 됩니다.

Supabase처럼 브라우저에서 임의의 테이블 쿼리를 조합하는 방식과는 학습 포인트가 다릅니다.

Firebase SQL Connect에서는 앱이 사용할 스키마와 operation을 선언하고, 생성된 SDK를 통해 호출하는 흐름이 중심입니다.

같은 TaskFlow를 만들 때 책임이 어떻게 달라질까

TaskFlow의 요구사항을 다음처럼 가정하겠습니다.

사용자 회원가입
로그인
내 작업 목록 조회
작업 추가
작업 완료 처리
작업 삭제
다른 사용자의 작업 접근 차단
프로필 정보 연결

Supabase에서는 다음 책임을 연결할 수 있습니다.

Auth
→ 사용자 식별

Postgres
→ profiles / tasks 저장

GRANT
→ authenticated가 할 수 있는 SQL 작업

RLS
→ 자신의 행만 접근

supabase-js / @supabase/ssr
→ 브라우저와 Next.js 서버 연결

Neon을 사용한다면 Managed Better Auth·Data API를 활용할지, 다른 인증 서비스·ORM·서버 API를 조합할지 선택합니다. 데이터베이스 브랜칭과 인증·API의 결합 방식까지 비교해야 합니다.

Firebase SQL Connect를 사용한다면 Firebase Auth와 SQL Connect schema, query, mutation, 생성 SDK를 중심으로 설계하게 됩니다.

TaskFlow에서 Supabase를 선택하는 이유

이 과정의 목적은 어떤 제품이 절대적으로 우수하다고 결론내리는 것이 아닙니다.

TaskFlow 과정에서 Supabase를 선택하는 이유는 학습 목표와 잘 맞기 때문입니다.

이번 과정에서는 다음을 한 흐름에서 직접 확인하고 싶습니다.

로그인
↓
JWT 사용자 신원
↓
Postgres 역할
↓
GRANT
↓
RLS
↓
사용자별 행 접근
↓
Next.js SSR 쿠키

Supabase는 이 흐름을 비교적 작은 프로젝트에서 그대로 관찰할 수 있습니다.

또한 앞선 Firebase 과정과 결과를 덮어쓰지 않습니다.

두 과정은 같은 Next.js TaskFlow 최종 상태에서 갈라지는 선택형 트랙입니다.

Next.js TaskFlow
├─ Firebase 백엔드
└─ Supabase 백엔드

Firebase를 먼저 끝냈다고 해서 Supabase 과정에서 Firebase 코드를 제거하는 방식으로 진행하지 않습니다.

자주 생기는 비교 오류

SQL을 쓰니 모두 같은 제품이라고 생각하기

PostgreSQL을 사용한다는 사실만으로 제품의 책임 범위가 같아지지 않습니다.

DB 제공, API 생성, 인증, Storage, SDK 생성 방식이 서로 다릅니다.

publishable key를 비밀키처럼 생각하기

Supabase publishable key는 공개 환경에서 사용할 수 있는 키입니다.

실제 사용자 데이터 보호는 GRANT와 RLS가 담당해야 합니다.

secret key를 브라우저에 넣기

secret key는 서버 전용 고권한 키이며 service_role 권한으로 RLS를 우회합니다.

브라우저 코드나 NEXT_PUBLIC_ 환경 변수에 넣으면 안 됩니다.

가격표만 보고 선택하기

각 서비스는 과금되는 자원과 포함 기능이 다릅니다.

가격은 서비스 구조와 사용량을 함께 봐야 하며, 구체적인 한도는 도입 시점 공식 요금표를 다시 확인하는 편이 안전합니다.

학습 완료 체크리스트

• Supabase와 Neon이 같은 범위의 제품이 아니라는 것을 설명할 수 있습니다.
• Firebase SQL Connect가 Firebase 앱과 PostgreSQL을 연결하는 서비스라는 것을 알고 있습니다.
• Supabase에서 publishable key만으로 보안이 완성되지 않는 이유를 설명할 수 있습니다.
• TaskFlow에서 Supabase를 선택하는 학습 목적을 설명할 수 있습니다.
• Firebase와 Supabase가 선택형 백엔드 브랜치라는 것을 이해했습니다.

next-step-38-cache-update

TaskFlow
Next.js App Router
React
TypeScript
서버/클라이언트 역할 분리
학습용 인증·데이터 계층
실제 운영 Postgres 미연결

docs/
└─ backend-choice.md

# TaskFlow Backend Choice


## 시작점


next-step-38-cache-update


## 선택


Supabase


## 이유


- PostgreSQL 관계형 데이터 모델을 직접 학습한다.
- Supabase Auth와 Postgres 사용자를 연결한다.
- GRANT와 RLS를 이용해 사용자별 데이터 격리를 학습한다.
- Next.js App Router에서 쿠키 기반 SSR 인증을 연결한다.
- 관계 조회와 인덱스까지 하나의 데이터 계층에서 학습한다.


## 이번 과정에서 사용하는 기능


- PostgreSQL
- Auth
- Data API
- Row Level Security
- @supabase/supabase-js
- @supabase/ssr


## 이번 과정에서 필수로 다루지 않는 기능


- Realtime
- Storage
- Edge Functions


필요 기능이 아니므로 과정 범위를 무리하게 늘리지 않는다.


## 보안 원칙


- 브라우저에는 publishable key만 사용한다.
- secret key는 클라이언트에 포함하지 않는다.
- 사용자 데이터는 RLS를 활성화한다.
- 화면에서 숨기는 것으로 권한 검증을 대신하지 않는다.
- 실제 인증 토큰과 개인정보를 학습 자료에 저장하지 않는다.


## 백엔드 트랙


Firebase 완료본을 이어서 수정하지 않는다.


Next.js TaskFlow 최종 체크포인트에서 별도 Supabase 브랜치를 시작한다.


## 다음 단계


Supabase 프로젝트를 만들고 공개 학습 데이터를 한 번 조회한다.

# Supabase 01 완료 체크포인트 — backend-choice

백엔드 선택 기록 문서입니다. 실행 앱이나 설치 의존성이 없습니다. docs/backend-choice.md를 읽고 본인 프로젝트의 선택 근거를 작성하세요.

Before

실제 백엔드 선택 기준이 없음
백엔드 과정별 책임 경계가 모호함

After

Supabase 선택 이유 문서화
Postgres + Auth + RLS 학습 범위 확정
Firebase와 별도 브랜치 확정

supabase-step-01-backend-choice

다음 학습

다음 글에서는 실제 Supabase 프로젝트를 만들고 Next.js App Router에서 publishable key를 이용해 공개 데이터를 처음 조회합니다.

다음 글:

Next.js Supabase 연결 방법: App Router 설정과 데이터 조회

공식 문서

확인일: 2026-09-21

• Supabase API Keys: https://supabase.com/docs/guides/getting-started/api-keys
• Supabase Next.js Quickstart: https://supabase.com/docs/guides/getting-started/quickstarts/nextjs
• Neon Docs: https://neon.com/docs/
• Neon Managed Better Auth: https://neon.com/docs/auth/overview
• Neon Data API: https://neon.com/docs/data-api/overview
• Firebase SQL Connect: https://firebase.google.com/docs/sql-connect