Neon, PlanetScale, Turso 중 선택하는 것은 결국 세 가지 근본적으로 다른 선택지를 고르는 것입니다: Postgres, MySQL/Vitess, 그리고 엣지에서의 SQLite. 지난해 동안 시장은 크게 변했습니다 - Databricks가 Neon을 약 10억 달러에 인수했고, PlanetScale이 Postgres 지원을 출시했으며, Turso는 스케일-투-제로를 중단했습니다. 2026년에 서버리스 데이터베이스를 선택하려고 한다면, 지금까지 읽은 비교글들은 아마도 구식일 겁니다.
Neon vs PlanetScale vs Turso 한눈에 보기
완전한 Postgres 호환성과 넉넉한 무료 티어, 그리고 최고의 Vercel 통합을 원한다면 Neon을 선택하세요. 엔터프라이즈급 수평 샤딩이 필요한 MySQL이라면 PlanetScale을 선택하세요. 엣지 레이턴시와 멀티테넌트 데이터베이스-퍼-유저 아키텍처가 중요하다면 Turso를 선택하세요.
이것이 빠른 답변입니다. 이 글의 나머지 부분은 각 선택지가 왜 그렇게 보이는지 자세히 설명합니다.
각 데이터베이스는 내부적으로 어떻게 작동할까요?
각 플랫폼을 구성하는 엔진이 쿼리 문법부터 스케일링 한계까지 모든 것을 결정합니다. 아키텍처를 이해하면 앱이 성장할 때 각각이 어떻게 행동할지 예측할 수 있습니다.
Neon: 브랜칭이 가능한 서버리스 Postgres
Neon은 컴퓨팅과 스토리지를 완전히 분리합니다. Postgres 컴퓨팅 노드는 임시적으로, 쿼리가 도착할 때 시작되고 유휴 상태일 때 축소됩니다(또는 0으로). 스토리지는 별도의 pageserver 레이어에 있어 내구성과 시점 복구를 처리합니다.
이 아키텍처는 Neon의 킬러 기능을 가능하게 합니다: 복사-온-라이트 브랜칭. 데이터베이스 브랜치를 생성하는 것은 크기와 관계없이 거의 즉시입니다. 왜냐하면 데이터를 복사하지 않고 부모와 스토리지 페이지를 공유하며 데이터가 변경될 때만 새로운 페이지를 작성하기 때문입니다. 데이터베이스를 위한 git branch라고 생각하면 됩니다.
- 완전한 PostgreSQL 와이어 프로토콜 (pg_dump, psql, 모든 것이 작동)
- 0.25에서 56 CU까지 자동 스케일링 컴퓨팅
- PgBouncer를 통한 내장 연결 풀링
- Neon의 아키텍처는 쓰기 선행 로그 내구성을 위해 safekeepers를 사용합니다
PlanetScale: Vitess 기반 MySQL (그리고 이제 Postgres)
PlanetScale은 Vitess에서 실행됩니다. Vitess는 YouTube에서 원래 자신의 데이터베이스를 수만 개의 노드에 샤딩하기 위해 만든 MySQL 클러스터링 엔진입니다. MySQL을 위한 수평 스케일링이 필요하다면, Vitess는 존재하는 가장 전투 검증된 솔루션입니다.
PlanetScale의 특징적인 DX 기능은 배포 요청입니다. 기본적으로 스키마 변경을 위한 풀 요청입니다. 마이그레이션을 제안하고, 차이를 검토한 후, 무중단으로 적용합니다. 잠금도 없고, 유지 보수 시간도 없습니다.
2025년 9월 이래로, PlanetScale은 관리형 Postgres도 제공합니다. 이것은 Vitess 제공과는 다른 제품으로, $5/월부터 시작하는 단일 노드 Postgres 데이터베이스입니다. Postgres를 위한 수평 샤딩("Neki")은 아직 개발 중입니다.
Postgres가 MySQL보다 더 합리적인 경우(그리고 그 반대)에 대한 더 깊은 이해를 원한다면, PostgreSQL vs MySQL 비교를 확인하세요.
- Vitess: 수평 샤딩, 무중단 스키마 마이그레이션
- Postgres: 단일 노드, 프로덕션 준비, 하지만 샤딩은 아직 없음
- 안전하고 검토 가능한 스키마 변경을 위한 배포 요청
- 스케일-투-제로 없음, 데이터베이스는 항상 실행 중
Turso: libSQL을 사용한 엣지의 SQLite
Turso는 완전히 다른 접근 방식을 취합니다. 서버 기반 데이터베이스를 실행하는 대신, libSQL을 사용합니다. libSQL은 서버 모드 기능이 있는 SQLite의 오픈소스 포크입니다. 데이터는 엣지에 있을 수 있습니다. 말 그대로 애플리케이션 런타임에 내장되어 있습니다.
핵심 개념은 임베디드 레플리카입니다: 애플리케이션 프로세스(또는 엣지 위치) 내에서 실행되는 읽기 레플리카로 네트워크 레이턴시 없이 읽기를 수행합니다. 쓰기는 주 인스턴스로 이동하고 레플리카로 비동기적으로 전파됩니다.
- libSQL은 HTTP 접근, 레플리케이션, 멀티테넌시로 SQLite를 확장합니다
- 데이터베이스-퍼-유저 모델은 수천 개의 격리된 데이터베이스를 지원합니다
- 쓰기는 주에서 레플리카로 밀리초 단위로 전파됩니다
- 읽기 집중, 전역 분산 앱에 이상적입니다
평가: 아키텍처 폭에서 Neon이 우승합니다. 즉시 브랜칭이 가능한 완전한 Postgres는 가장 광범위한 사용 사례를 다룹니다. 특히 Vitess급 수평 샤딩이 필요한 경우 PlanetScale이 우승합니다. 엣지에서 데이터가 필요한 경우 Turso가 우승합니다.
성능과 레이턴시는 어떻게 비교될까요?
성능은 개발자가 가장 먼저 묻는 질문이고, 답변은 전적으로 데이터베이스가 워밍된(warm) 상태인지 콜드 상태인지에 따라 달라집니다.
콜드 스타트 현실 확인
Neon은 세 개 중 유일하게 기본적으로 여전히 스케일-투-제로를 수행합니다. 컴퓨팅 노드가 유휴에서 깨어날 때, 첫 번째 쿼리에서 400-750ms를 예상하세요. 후속 쿼리는 빠릅니다. 최소 컴퓨팅 크기를 설정하여 콜드 스타트를 제거할 수 있습니다(0.25 CU의 비용은 대략 $7/월).
PlanetScale은 항상 켜져 있으며, 콜드 스타트가 없습니다. 데이터베이스는 아무도 쿼리하지 않아도 실행 중입니다.
Turso는 2025년 1월에 새 사용자를 위한 스케일-투-제로를 중단했습니다. 새 가입자는 항상 켜진 인스턴스를 받으므로 콜드 스타트는 없지만 "유휴 시 비용 없음" 절감도 없습니다.
엣지 레이턴시: Turso가 빛나는 곳
핫 쿼리의 경우, 세 개 모두 빠릅니다. 하지만 Turso의 임베디드 레플리카는 다른 두 개가 할 수 없는 것을 제공합니다: 엣지에서의 한 자릿수 밀리초 읽기. SQLite 레플리카가 Cloudflare Worker 또는 Vercel Edge Function과 같은 코드와 동일한 위치에 있을 때, 읽기를 위한 네트워크 홉이 전혀 없습니다.
Pilcrow(2023년 7월 - 현재 수치가 아닌 참고용)의 벤치마크 데이터는 PlanetScale HTTP에서 ~8ms, Neon HTTP에서 ~5ms, 그리고 중앙화된 쿼리를 위해 Turso HTTP에서 ~27ms를 보였습니다. Cloudflare Workers의 독립적인 벤치마크는 유사한 패턴을 확인했습니다. 이 수치는 PlanetScale의 Postgres 출시와 Turso의 인프라 변경 전이므로, 이를 절대적 기준이 아닌 참고점으로 취급하세요.
평가: 엣지 레이턴시는 Turso가 우승합니다. 네트워크 홉 없는 임베디드 레플리카 읽기는 비할 수 없습니다. 콜드 스타트 우려 없는 중앙화된 워크로드의 경우, PlanetScale의 항상 켜진 일관성은 이기기 어렵습니다. Neon의 콜드 스타트는 스케일-투-제로 절감의 트레이드오프입니다.
각 데이터베이스는 실제로 얼마나 비용이 들까요?
이것은 대부분의 비교글이 부족한 곳입니다. 계획 가격을 나열하지만 실제 앱이 얼마를 지불할지는 계산하지 않습니다. 이를 해결해봅시다.
무료 티어 분석
PlanetScale은 2024년 4월에 무료 Hobby 티어를 제거했습니다. 가장 저렴한 진입점은 이제 단일 노드 Postgres 데이터베이스를 위한 $5/월입니다. Vitess/MySQL 데이터베이스의 경우, 가격 책정은 클러스터 기반이고 훨씬 높습니다.
네 가지 스케일 계층에서의 실제 월간 비용
이 추정치는 각 플랫폼의 공식 가격 책정 페이지에서 현재 2026년 가격을 사용합니다. 실제 비용은 사용 패턴에 따라 다릅니다.
몇 가지가 눈에 띕니다. Turso는 읽기 집중 앱을 선호하는 행 읽기 가격 책정 모델 때문에 낮은 및 중간 계층에서 놀랍도록 저렴합니다. Neon의 사용량 기반 가격 책정은 소비한 것에 대해서만 지불하고 무료 티어에서 유휴 데이터베이스는 비용이 없다는 의미입니다. PlanetScale의 가격 책정은 Postgres 단일 노드에 대해 경쟁력이 있지만 Vitess 클러스터로 확대됩니다.
PlanetScale 가격 책정 절벽
솔로 개발자를 위한 PlanetScale의 가장 큰 약점: 무료 티어가 없습니다. $0(경쟁자 사용)에서 $5/월 최소로 이동합니다. 자금이 있는 스타트업의 경우 이것은 무관하지만, 사이드 프로젝트와 프로토타이핑의 경우, Neon과 Turso의 무료 티어가 의미있게 더 낫습니다.
반면, PlanetScale의 Vitess 제공은 Neon도 Turso도 일치시킬 수 없는 수평 샤딩을 제공합니다. 쓰기 처리량이 샤딩을 요구한다면, 프리미엄은 정당화됩니다.
평가: 대부분의 예산에서 Neon이 우승합니다. 무료 티어 플러스 사용량 기반 가격 책정이 가장 유연한 모델입니다. Turso의 행 읽기 가격 책정은 읽기 집중 앱에 탁월합니다. PlanetScale은 낮은 끝에서 더 비용이 들지만 엔터프라이즈급 스케일링을 제공합니다.
개발자 경험은 어떻습니까?
일상적인 DX는 벤치마크 수치보다 중요합니다. 실제로 사용할 기능에서 세 개가 어떻게 비교되는지 설명합니다.
데이터베이스 브랜칭과 CI/CD
Neon의 복사-온-라이트 브랜칭이 황금 기준입니다. 모든 PR마다 브랜치를 생성하고, 마이그레이션을 실행하고, 프로덕션과 같은 데이터로 테스트한 후 병합합니다. Vercel 통합은 미리 보기 배포마다 자동으로 브랜치를 생성합니다.
...