개인 사이트나 문서 사이트를 Vercel·Cloudflare 에 올리다 보면 "DB 를 어디에 두느냐" 가 곧 지연과 비용 문제로 돌아옵니다. 이 글은 특정 벤더 튜토리얼이 아니라, 엣지에 SQLite 를 둔다는 말이 무엇인지를 데이터 플레인 그림으로 정리한 것입니다. PostgreSQL 중심의 글은 이미 썼으니(Supabase 가이드), 이번에는 SQLite 가 붙는 위치와, 이 블로그의 조회수·좋아요 저장소를 엣지 SQLite 로 옮길지 검토하면서 실제로 확인한 것에 초점을 맞춥니다.
리전 DB 와 엣지 SQLite 를 한 장에#
한 리전에 Primary DB 가 있으면, 멀리 있는 사용자는 왕복 지연(RTT) 을 그대로 감수합니다. 서울 리전 DB 에 미국 사용자가 접속하면 요청마다 수백 밀리초가 붙습니다. 엣지 SQLite 계열은 사용자와 가까운 지점(PoP)에 읽기 경로를 두는 그림입니다.
여기서 주의할 것은 복제·일관성·쓰기 라우팅 규칙이 제품마다 완전히 다르다 는 점입니다. 어떤 제품은 쓰기를 한 곳(Primary)으로 보내고 읽기 복제본을 여러 지역에 두며, 어떤 제품은 데이터베이스 자체를 한 지역에 두고 엣지 함수만 가까이 둡니다. "SQLite 라서 다 같다" 고 보면 설계가 틀어집니다. 제품 문서에서 "쓰기는 어디로 가는가" 를 그린 그림부터 찾는 것이 순서입니다.
워크로드별 적합도#
아래 표는 설계 회의에서 질문을 던지기 위한 거친 구분입니다. 정밀한 비용·SLA 비교는 각자의 트래픽 패턴을 넣고 계산해야 합니다.
| 워크로드 | 엣지 SQLite 적합도 | 이유 |
|---|---|---|
| 블로그·카탈로그·문서처럼 읽기가 대부분 | 높음 | 읽기 복제본이 가까이 있으면 그대로 이득. 캐시와 달리 SQL 조건 조회가 됨 |
| 조회수·좋아요처럼 쓰기가 잦지만 정확성 요구가 낮음 | 중간 | 쓰기가 Primary 로 가면 지연이 붙고, 복제 지연 동안 숫자가 잠깐 안 맞을 수 있음 |
| 글로벌 대시보드처럼 쓰기와 집계가 많음 | 낮음 | 동시 쓰기·권한·집계를 어떻게 나눌지 먼저 정하지 않으면 복잡도만 올라감 |
| 결제·재고처럼 강한 ACID 가 필요 | 낮음 | 리전 DB + 큐가 기본안. 엣지는 읽기 모델·캐시와 짝을 이뤄야 함 |
검토하면서 실제로 확인한 것#
이 블로그의 조회수·좋아요 저장소를 엣지 SQLite 로 옮길지 검토했습니다. 지금은 리전 PostgreSQL 에 있습니다. 확인한 질문과 결과입니다.
쓰기는 어디로 가는가. 검토한 제품은 쓰기를 Primary 로 보내고 읽기 복제본을 지역별로 두는 방식이었습니다. 조회수 증가는 요청마다 쓰기가 일어나므로, 한국 밖 사용자의 쓰기 지연은 리전 DB 때와 비슷했습니다. 읽기만 빨라지는 구조입니다. 조회수를 "요청마다 쓰기" 대신 "배치로 모아 쓰기" 로 바꾸면 이득이 커지는데, 그건 DB 를 바꾸지 않아도 할 수 있는 개선이었습니다.
마이그레이션은 누가 주도하는가. 로컬·CI·프로덕션에서 같은 스키마를 유지하는 도구가 제품마다 달랐습니다. 기존 PostgreSQL 마이그레이션 도구를 그대로 쓸 수 없어서, 옮기면 마이그레이션 파이프라인을 다시 짜야 했습니다. 작은 테이블 두 개를 위해 감수할 비용은 아니었습니다.
관측성은. 지연 분포와 에러율을 리전 DB 때만큼 볼 수 있는지가 중요했습니다. 지역별 복제본의 지연을 따로 보려면 로그·메트릭 파이프를 새로 그려야 했습니다.
결론. 옮기지 않았습니다. 읽기 지연은 이미 페이지 캐시가 해결하고 있었고, 쓰기는 엣지로 가도 빨라지지 않으며, 마이그레이션과 관측 비용이 이득보다 컸습니다. 대신 조회수 쓰기를 배치로 바꾸는 쪽으로 방향을 잡았습니다. 엣지 SQLite 가 나빠서가 아니라, 이 워크로드가 "읽기 위주 + 가벼운 쓰기" 라 캐시로 충분했기 때문입니다.
반대로 문서 사이트처럼 쓰기가 거의 없고 검색·필터가 필요한 곳 이었다면 결론이 달랐을 것입니다. 거기서는 엣지에서 SQL 을 바로 치는 이점이 그대로 살아납니다.
Next.js 개발자에게 던지는 질문 세 가지#
- 쓰기는 어디로 가는가. 엣지 함수에서 직접 쓰는지, 중앙으로 모아 쓰는지부터 정합니다. 이 그림이 없으면 "엣지" 라는 말이 지연 개선을 보장하지 않습니다.
- 마이그레이션은 누가 주도하는가. 로컬·CI·프로덕션에서 같은 스키마를 유지할 도구와 절차를 확인합니다. 기존 도구를 못 쓰면 그 비용을 계산에 넣습니다.
- 관측성은. 지연 분포와 에러율을 지역별로 볼 수 있는지, 없으면 로그·메트릭 파이프를 미리 그립니다.
정리#
엣지 SQLite 는 "가벼운 데이터를 가까이 둔다" 는 매력이 큰 대신, 복제 모델을 잘못 이해하면 밤중에 깨는 장애로 돌아옵니다. 정적·MDX 비중이 큰 사이트는 캐시만으로 충분한 경우가 많고, 팀 단위 제품은 리전 DB 를 중심에 두고 엣지는 읽기 최적화로 쓰는 것이 여전히 보수적이고 좋은 선택인 경우가 많습니다. 제품을 고를 때는 데모가 빠른지보다 쓰기 경로 다이어그램 을 먼저 요청해 보세요.
클라우드 비용 항목을 어떻게 읽는지는 클라우드 청구서 읽는 법에, 배포 플랫폼 선택은 Vercel·Netlify·Cloudflare 비교에 정리해 두었습니다.
