Neon·Supabase 비교: 쿼리 지연은 비슷, 시작은 20배 차이

동일 지역 반복 측정에서 새 프로젝트가 첫 쿼리에 응답하기까지 걸린 시간의 중앙값은 Neon 5.5초, Supabase Pro 111.9초로 약 20배 차이가 났다. 반면 새 연결을 맺고 TLS와 인증을 거쳐 간단한 쿼리를 실행한 지연의 중앙값은 양쪽 모두 약 32밀리초였다. 큰 격차가 난 것은 평소 쿼리 실행이 아니라 새 프로젝트를 준비하는 단계다.

새 SaaS나 웹앱이 오래 쉬었다가 간헐적으로 요청을 처리하고 PostgreSQL 중심으로 구성된다면 Neon의 사용량 과금이 유리할 수 있다. 인증, 파일 저장소, 실시간 기능까지 함께 필요한 앱이라면 Supabase의 통합 요금이 비교의 출발점이다. 다만 Neon에도 인증·스토리지·Functions가 있으므로 기능의 유무만으로 결론을 내릴 수 없다. 한국에 앱 서버를 둘 계획이라면 두 서비스의 데이터베이스 리전 차이도 비용과 함께 봐야 한다.

시작 시간과 평소 응답 시간은 다른 지표다

프로젝트 생성 측정은 API 요청으로 새 프로젝트를 만든 시점부터 SQL에 처음 응답할 때까지를 재었다. 고객별 데이터베이스를 자동으로 열거나 테스트마다 독립된 환경을 만드는 서비스라면 이 대기 시간이 실제 작업 흐름에 들어간다. 반대로 이미 만들어진 데이터베이스를 계속 사용하는 앱에서는 생성 시간보다 연결 관리와 운영 중 쿼리 지연이 더 자주 영향을 미친다.

연결 지연 측정에는 네트워크 연결, TLS, 인증, 가벼운 쿼리가 함께 들어간다. 순수한 SQL 실행 시간만 잰 값으로 읽으면 안 된다. 연결 풀을 재사용하거나 여러 테이블을 조인하는 앱에서는 측정한 작업 자체가 달라진다. 데이터 크기, 인덱스, 앱 서버 위치까지 바뀌면 실제 요청의 응답 시간도 달라질 수 있다.

유휴 데이터베이스가 다시 깨어나는 시간도 새 프로젝트의 첫 가동과 구별해야 한다. 밤새 요청이 없다가 아침에 사용자가 돌아오는 서비스는 기존 컴퓨트의 재개 지연을 겪을 수 있다. 고객마다 환경을 새로 만드는 서비스는 프로젝트 생성 대기를 겪는다. 두 상황을 같은 ‘콜드 스타트’로 묶으면 정작 이용자에게 보이는 지연이 어디에서 생기는지 놓치게 된다.

측정 클라이언트와 두 데이터베이스는 프랑크푸르트 인근의 같은 지역에 놓였다. 이는 서비스 간 비교에서 네트워크 거리의 영향을 줄이는 조건이다. 한국 이용자가 서울의 앱 서버를 거쳐 데이터베이스에 접근하는 경로는 다르므로, 이 결과를 국내 서비스의 전체 응답 시간으로 옮겨 적용할 수는 없다.

유휴 시간이 긴 앱은 Neon의 실행 시간을 계산해야 한다

Neon의 PostgreSQL 데이터가 브랜치로 분기되고 유휴 컴퓨트가 중단되는 구조

Neon 요금표에서 Launch의 데이터베이스 컴퓨트는 CU-hour당 0.106달러, 저장량은 GB-month당 0.35달러이며 유료 플랜에 월 기본요금이나 최소 지출액이 없다. CU-hour는 컴퓨트 크기와 실행 시간을 함께 반영한다. 데이터베이스가 쉬는 동안 컴퓨트를 중단하면 그 시간의 컴퓨트 사용량을 줄일 수 있어, 운영 패턴이 청구액에 직접 연결된다.

업무 시간에만 열리는 내부 도구나 간헐적으로 실행되는 테스트 환경에서는 사용하지 않는 시간이 비용상 의미를 갖는다. 하루 내내 고르게 요청이 들어오는 앱에서는 컴퓨트가 쉬기 어렵다. 따라서 같은 월간 방문자 수라도 요청이 특정 시간에 몰리는지, 짧은 간격으로 계속 도착하는지에 따라 Neon의 사용량이 달라진다.

저장량만 더해 월 비용을 끝냈다고 볼 수도 없다. 복구를 위한 변경 이력, 추가 브랜치, 백업과 외부 전송량은 별도의 비용 항목이 될 수 있다. 개발 환경을 자주 만들고 지우는 팀이라면 브랜치가 얼마나 오래 남아 있는지도 계산에 포함해야 한다. 사용량 과금의 장점은 쉬는 시간을 반영할 수 있다는 데 있고, 그만큼 실제 사용 패턴을 알아야 예상 청구액도 구체화된다.

상시 트래픽에서는 평균 컴퓨트 크기에 실행 시간을 곱한 값이 비교의 중심이 된다. 자동 확장은 바쁜 시간에 컴퓨트 크기를 맞추는 기능이지만, 조용한 시간에도 요청이 이어진다면 컴퓨트가 완전히 중단되지는 않는다. 항상 켜져 있어야 하는 작업이나 지속적인 연결이 필요한 서비스라면 ‘서버리스’라는 이름만으로 월 비용이 낮을 것이라고 판단하기 어렵다.

Supabase 비용은 데이터베이스 밖에서 달라진다

Supabase 요금표는 Pro 조직 구독료를 월 25달러로 제시하고, 유료 조직에 월 10달러의 컴퓨트 크레딧을 제공한다. 이 크레딧은 기본 Micro 컴퓨트의 비용을 충당할 수 있다. 각 프로젝트에는 전용 PostgreSQL 인스턴스가 있으므로 프로젝트를 추가하거나 컴퓨트 크기를 키우면 구독료 외 비용이 생길 수 있다.

Supabase에서는 인증 사용자, 파일 저장량과 전송량, Edge Functions 호출, Realtime 연결과 메시지까지 같은 플랫폼의 청구 구조에 들어간다. 로그인과 이미지 업로드, 실시간 알림을 요구하는 앱이라면 데이터베이스 가격만 따로 떼어 비교할 이유가 작다. 외부 인증 서비스와 오브젝트 스토리지를 조합할 경우의 사용료와 운영 부담도 같은 범위에 넣어야 한다.

반대로 로그인이나 파일 업로드가 없는 내부 API라면 통합 기능의 가치가 작아진다. 이 경우 데이터베이스 컴퓨트와 저장량, 백업, 전송량을 중심으로 비교하는 편이 명확하다. Supabase의 시작 구독료와 Neon의 컴퓨트 단가를 바로 맞대는 계산은 단위부터 다르다. 한쪽은 조직 구독과 프로젝트별 컴퓨트 크레딧을 포함하고, 다른 쪽은 실제로 사용한 데이터베이스 자원을 중심으로 청구한다.

앱이 커질수록 포함량을 넘는 항목도 달라진다. 인증 사용자가 늘어나는 서비스와 큰 파일을 자주 전달하는 서비스는 비용을 밀어 올리는 항목이 같지 않다. 따라서 초기 프로젝트의 청구액이 낮다는 사실만으로 성장 후의 순서를 예측하기 어렵다. 필요한 기능의 사용량을 함께 놓아야 앱 전체 비용을 비교할 수 있다.

인증·스토리지와 브랜치는 선택 기준을 바꾼다

Neon도 Managed Better Auth, Object Storage, Functions를 제공한다. PostgreSQL만 제공하는 상품으로 전제하고 외부 인증과 저장소의 비용을 무조건 더하면 현재의 비교가 틀어진다. 다만 데이터베이스 컴퓨트의 CU-hour와 오브젝트 스토리지·Functions의 청구 단위는 서로 다르다. 백엔드 기능을 더할수록 데이터베이스 비용과 앱 전체 비용을 분리해 보는 것이 유용하다.

Supabase는 PostgreSQL과 인증, 파일 저장소, 실시간 기능을 한 프로젝트에서 다룬다. 이런 기능을 제품 출시 때부터 모두 쓸 앱이라면 통합 구조가 개발과 청구를 단순하게 만들 수 있다. Neon의 데이터베이스 사용량 과금이 매력적이어도, 필요한 기능을 함께 운영할 때의 비용과 구성은 별도로 비교해야 한다. 특히 실시간 메시지가 제품의 핵심이라면 PostgreSQL 요금만으로 결론을 낼 수 없다.

개발 환경을 자주 복제한다면 브랜치의 내용도 중요하다. 기존 데이터를 포함한 쓰기 가능한 브랜치와 스키마만 가져오는 브랜치는 테스트에 제공하는 출발점이 다르다. 고객 데이터에 가까운 상태에서 변경을 검증하려는 팀은 데이터가 어떻게 이어지는지 살펴야 한다. 환경을 거의 복제하지 않는 서비스라면 브랜치 생성 속도보다 운영 중 비용과 응답 경로가 더 큰 판단 근거가 된다.

한국 배포에서는 데이터베이스의 위치가 별도 변수다

한국 앱 서버와 Supabase 서울 리전, Neon 싱가포르 리전의 위치 관계

Neon 리전 목록에는 싱가포르가 있지만 서울은 없다. 같은 목록에서 싱가포르는 PostgreSQL, Managed Better Auth, Object Storage, Functions가 제공되는 지역으로 표시된다. Neon 프로젝트의 리전은 생성할 때 정하며, 기존 프로젝트의 리전을 바꾸려면 새 프로젝트로 데이터를 옮겨야 한다.

Supabase 리전 목록에는 서울의 ap-northeast-2가 있다. 한국에 앱 서버를 두는 서비스라면 데이터베이스도 서울에 둘 수 있다는 점이 실질적인 차이다. 앱 서버에서 데이터베이스로 여러 차례 왕복하는 요청은 두 위치 사이의 거리에 영향을 받을 수 있다. 다만 같은 도시의 리전을 선택해도 쿼리 설계나 연결 방식에서 생기는 지연까지 사라지지는 않는다.

프랑크푸르트에서의 동일 지역 결과는 각 서비스를 같은 조건에서 비교한 자료로 읽어야 한다. 서울 앱 서버와 싱가포르 데이터베이스를 연결하는 경우에는 그 측정에 없던 지역 간 왕복이 들어간다. 한국 배포에서는 데이터베이스 리전뿐 아니라 앱 서버, 인증, 파일 전송이 실제로 지나는 경로가 중요하다. 원격 데이터베이스를 반복 호출하는 설계일수록 위치 차이가 요청에 누적될 가능성이 크다.

워크로드에 따라 유리한 계산식이 다르다

유휴 시간이 긴 서비스는 Neon의 컴퓨트 중단과 사용량 과금에서 이익을 얻을 여지가 크다. 고객별 환경이나 미리보기 데이터베이스를 자주 만드는 팀에는 빠른 프로젝트 생성도 별도의 이점이다. 다만 이용자가 쉬는 시간 뒤 보낸 첫 요청의 재개 지연은 프로젝트 생성 시간과 다른 문제이며, 한국 서버에서 싱가포르 리전으로 향하는 경로도 고려해야 한다.

상시 트래픽 서비스는 어느 쪽이 무조건 싸다고 단정하기 어렵다. Neon에서는 평균 CU와 실행 시간이, Supabase에서는 조직 구독료와 프로젝트별 컴퓨트 크기가 출발점이다. 저장량, 백업, 전송량과 필요한 백엔드 기능을 더하면 비용의 순서가 바뀔 수 있다. 프로젝트를 빨리 만든다는 결과만으로 운영 중인 쿼리 비용이나 응답 속도를 판정할 수는 없다.

인증·파일·실시간 기능이 필요한 앱에는 Supabase의 통합 구성이 직접적인 후보가 된다. Neon의 백엔드 기능도 후보에 넣을 수 있지만, 필요한 서비스가 선택한 리전에서 제공되는지와 각 사용량이 어떻게 청구되는지를 함께 봐야 한다. 한국 이용자를 대상으로 한다면 서울 배포 가능성과 앱 서버에서 데이터베이스까지의 호출 경로가 최종 비용만큼 중요한 선택 조건이다.

함께 읽기: