개인 사이트나 문서 사이트를 Vercel·Cloudflare 쪽에 올리다 보면, **“DB를 어디에 두느냐”**가 곧 지연과 비용 문제로 돌아옵니다. 이 글은 특정 벤더 튜토리얼이 아니라, 엣지에 SQLite를 둔다는 말이 무엇인지를 데이터 플레인 그림으로만 정리했어요. PostgreSQL 중심으로 이미 글을 쓴 적이 있어서(Supabase 가이드 등), 이번에는 SQLite가 붙는 위치에 초점을 맞췄습니다.
리전 DB vs 엣지 SQLite를 한 장에
한 리전에 Primary DB가 있으면, 멀리 있는 사용자는 **왕복 지연(RTT)**을 그대로 감수합니다. 반면 엣지 SQLite 계열은 사용자 가까운 PoP에 읽기 경로를 붙이는 상상을 합니다. 복제·일관성·쓰기 라우팅 규칙은 제품마다 완전히 다르니, “SQLite라서 다 같다”고 보면 안 됩니다.
워크로드별로 적합도만 나눠 보기
아래 표는 설계 회의에서 질문을 던지기 위한 거친 구분입니다. 정밀한 TCO나 SLA 비교는 각자의 트래픽 패턴을 넣고 계산해야 해요.
- 블로그·카탈로그·읽기 위주 API: 캐시 한 장 올리는 것과 달리, 엣지에서 SQL을 태우는 그림이 됩니다. 지연에 민감하면 후보로 좋아요.
- 글로벌 대시보드처럼 쓰기가 많은 화면: 동시 쓰기·집계·권한 모델을 어떻게 나눌지 먼저 정하지 않으면 엣지 DB가 오히려 복잡도만 올릴 수 있어요.
- 결제·재고처럼 강한 ACID가 필요한 도메인: 보통은 리전 DB + 큐가 기본안이고, 엣지는 읽기 모델·캐시·동기화 파이프라인과 짝을 이뤄야 합니다.
Next.js 개발자에게 던지는 질문 세 가지
- 쓰기는 어디로 가는가? 엣지 함수에서 직접 쓰는지, 중앙으로 모아 쓰는지부터 정해야 합니다.
- 마이그레이션은 누가 주도하는가? 로컬·CI·프로덕션에서 같은 스키마를 유지할 수 있는지 확인하세요.
- 관측성은? 지연 분포와 에러율을 리전 DB 때만큼은 볼 수 있게 로그·메트릭 파이프를 미리 그려 두는 편이 안전합니다.
정리
엣지 SQLite는 **“가벼운 데이터를 가까이 둔다”**는 매력이 큰 대신, 복제 모델을 잘못 이해하면 밤중에 깨는 장애로 돌아오기도 합니다. 이 블로그처럼 정적·MDX 비중이 크면 Postgres까지 가지 않아도 되는 경우도 많고, 반대로 팀 단위 제품이면 리전 DB를 중심에 두고 엣지는 읽기 최적화가 여전히 보수적이고 좋은 선택인 경우가 많아요. 제품을 고를 때는 “데모가 빠른지”보다 쓰기 경로 다이어그램을 먼저 요청해 보세요.