바이브 코딩 데이터베이스 선택 가이드: Supabase, D1, Turso, MongoDB 찍고 VPS Postgres까지 온 이유

바이브 코딩에서 DB 선택이 어려운 이유는 “DB”라는 말 안에 너무 많은 물건이 들어 있기 때문입니다. Postgres, MongoDB, Redis, R2, Firestore, ClickHouse, 벡터 DB는 같은 후보군처럼 보이지만 실제 역할은 다릅니다.

그래서 이 글은 경험담만 말하지 않습니다. 먼저 어떤 DB 종류가 있는지, 어떤 서비스가 있는지, 어떤 과금 단위를 조심해야 하는지, 그리고 실제 운영에서 어떤 실수를 피해야 하는지를 순서대로 정리합니다.

바이브 코딩으로 앱을 만들면 화면, API, 관리자 페이지는 생각보다 빨리 나옵니다. 문제는 그 다음입니다. 방문자가 들어오고, 크론이 돌고, 유튜브 데이터를 수집하고, 통계를 갱신하기 시작하면 “이 데이터는 어디에 둘 것인가”가 바로 돈 문제로 바뀝니다.

저는 Supabase를 쓰다가 월 $25가 부담스러웠고, Cloudflare D1은 Pages/Workers와 붙어서 좋아 보였지만 쓰기 폭탄을 맞았습니다. Turso도 만만히 봤다가 rows read/written 구조를 다시 봤고, MongoDB도 문서형이라 편할 줄 알고 구축했다가 fetch 체감 지연 때문에 다시 분해했습니다.

Supabase 같은 관리형 Postgres는 보통 plan, compute, disk, egress 중심으로 봅니다. 공식 가격표 기준 Free에는 500MB DB, Pro는 $25/month부터 시작하고, API requests는 Unlimited로 표시되지만 DB 용량과 egress, compute 한도는 별도로 봐야 합니다.

반대로 Cloudflare D1은 서버리스 SQL이라 사용한 쿼리가 rows read, rows written으로 잡힙니다. 공식 문서에는 paid tier에서 월 25B rows read 포함 후 $0.001/M, 월 50M rows written 포함 후 $1/M로 설명되어 있습니다. 인덱스가 있는 컬럼을 쓰면 인덱스 갱신도 write row에 영향을 줄 수 있습니다.

Turso도 SQLite 감각이라 편하지만 plan별 rows read, rows written, sync 포함량을 봐야 합니다. 그래서 “SQL이니까 싸겠지”, “서버리스니까 자동으로 저렴하겠지”는 위험한 판단입니다.

예를 들어 방문 카운터 하나도 설계에 따라 비용이 달라집니다. 매 방문마다 `page_views`에 INSERT하면 쓰기량이 방문 수만큼 늘고, 매번 오늘 합계를 다시 계산하면 읽기량도 늘어납니다. 반대로 메모리/Redis에 잠깐 모았다가 1분 단위로 집계하거나, 원본 이벤트는 R2/S3에 묶어 두고 화면용 집계만 DB에 올리면 같은 기능도 훨씬 조용해집니다.

“Supabase냐 D1이냐”만 보면 선택지가 너무 좁습니다. 실제로는 관리형 Postgres, 서버리스 SQL, 문서형 BaaS, 캐시, 분석 DB, 검색 DB, 벡터 DB, 객체 저장소, VPS 자체 운영까지 역할별 후보가 따로 있습니다.

DB 선택은 “Postgres냐 MongoDB냐” 한 줄로 끝나지 않습니다. 관계형, 문서형, 캐시, 검색, 벡터, OLAP, 시계열처럼 목적이 다른 도구들이 있고, 같은 저장소라도 원본 DB인지 보조 인덱스인지에 따라 역할이 달라집니다.

비용도 이 분류를 알아야 읽힙니다. Redis는 원본 DB보다 버퍼에 가깝고, ClickHouse는 거래 처리보다 집계용이며, R2/S3는 SQL DB가 아니라 원본 파일 보관소입니다. 역할을 섞지 않는 것이 비용 절감의 첫 단계입니다.

DB 비용은 요금표에서만 결정되지 않습니다. 같은 Postgres, 같은 D1이라도 이벤트를 어떻게 저장하고, 인덱스를 어떻게 잡고, 재시도를 어떻게 처리하느냐에 따라 비용과 안정성이 완전히 달라집니다.

이 비용은 단순히 “트래픽이 많아서”가 아니었습니다. 매 방문마다 카운터를 쓰고, 매 크론마다 같은 영상과 채널을 다시 쓰고, 필터 통계를 만들려고 넓은 테이블을 계속 읽으면 사용자는 한 명이어도 DB는 계속 일합니다.

D1은 Cloudflare Pages와 Workers에 붙이기 정말 좋습니다. 작은 설정값, 앱 메타, 짧은 링크, 공개 페이지의 가벼운 조회용 데이터에는 여전히 좋은 선택입니다. 하지만 YouTube 트렌딩 영상 수집처럼 같은 셀을 계속 긁고, 채널별 current 값을 계속 갱신하고, 방문 카운트를 매번 INSERT/UPDATE하는 구조에서는 rows written이 빠르게 쌓입니다.

특히 D1의 rows read는 “화면에 반환된 행 수”가 아니라 “쿼리가 읽거나 스캔한 행 수” 관점입니다. 인덱스가 빠지거나 정렬·필터가 넓게 걸리면, 사용자는 20개만 보는데 DB는 수천~수백만 행을 읽을 수 있습니다.

Supabase는 비싼 만큼 편합니다. Auth, RLS, dashboard, Postgres, Storage까지 한 번에 들어옵니다. 그래서 개인정보가 있거나 로그인/권한/결제가 있는 서비스라면 여전히 관리형 DB가 맞습니다.

Turso는 SQLite 계열이라 로컬 수집과 작은 API에는 매력적입니다. 다만 대량 read/write가 반복되는 구조라면 D1과 마찬가지로 포함량과 초과 과금을 확인해야 합니다. MongoDB는 JSON 문서형이라 직관적이지만, 관계형 집계와 비용 민감한 분석 화면에서는 프로젝트 성격을 많이 탑니다.

VPS는 쉽게 말해 24시간 켜져 있는 컴퓨터를 빌리는 개념입니다. 그 위에 Docker로 Postgres를 올리면, request마다 돈을 내는 감각보다는 CPU, 메모리, 디스크, 네트워크 한도 안에서 직접 운영하는 구조가 됩니다.

유튜브 영상 제목, 채널 ID, 썸네일, 조회수, 공개 트렌딩 기록처럼 이미 공개된 데이터는 개인정보와 위험도가 다릅니다. 이런 데이터 50만, 100만, 200만, 300만 건을 실험하려면 서버리스 row 과금형 DB보다 VPS Postgres가 더 예측 가능할 수 있습니다.

• Docker Compose로 Postgres, backup job, pgAdmin/Adminer 같은 관리 도구를 분리한다.
• DB 포트는 인터넷에 바로 열지 말고, SSH 터널 또는 VPN 경유를 기본으로 둔다.
• 매일 dump, 주간 offsite backup, 복구 리허설까지 해야 백업이라고 부를 수 있다.
• YouTube 공개 데이터처럼 털려도 치명적이지 않은 데이터부터 올려 실험한다.
• 개인정보, 결제, 비밀번호, 민감 로그는 직접 운영 DB에 섞지 않는다.
• 인덱스, VACUUM, autovacuum, slow query log, 디스크 사용량을 주기적으로 본다.

제 기준은 이제 단순합니다. 보안·권한·결제가 핵심이면 돈을 내고 관리형을 씁니다. 공개 대량 데이터와 수집 실험이면 VPS Postgres를 검토합니다. Cloudflare 생태계의 작은 상태값은 D1에 둡니다. 로컬 수집과 가벼운 SQLite 감각은 Turso나 SQLite로 처리합니다.

이 글은 “무조건 VPS에 다 때려 넣자”가 아닙니다. 유튜브 공개 데이터처럼 털려도 피해가 제한적인 데이터와, 이메일·회원·결제·개인 로그처럼 유출되면 바로 사고가 되는 데이터는 완전히 다르게 봐야 합니다.

Auth가 필요하고 RLS가 중요하고 감사 로그와 백업, 보안 업데이트가 중요한 서비스라면 Supabase 같은 유료 클라우드 DB를 쓰는 것이 오히려 싸게 먹힐 수 있습니다. 직접 운영은 자유를 주지만 책임도 같이 줍니다.

제 결론은 단순합니다. 로그인과 권한은 관리형으로 안전하게, 공개 대량 데이터는 원본·스냅샷·집계를 분리해서, 반복 쓰기 기능은 버퍼링해서, 검색과 분석은 필요할 때 보조 저장소로 나눕니다. 이 순서를 지키면 DB 비용은 “운”이 아니라 설계 문제가 됩니다.

• 월요금이 아니라 과금 단위를 먼저 봤는가?
• 내 기능이 read-heavy인지 write-heavy인지, cron-heavy인지 구분했는가?
• 원본, current snapshot, aggregate, archive를 분리했는가?
• 방문 카운트와 반복 수집을 즉시 DB write로 처리하지 않는가?
• 개인정보/Auth/결제 데이터와 공개 대량 데이터를 분리했는가?
• 인덱스, 쿼리 스캔, backup, egress, budget alert까지 운영 항목에 넣었는가?

실제 도입 전에는 현재 사용하는 region, plan, storage, egress, read/write 단위를 기준으로 다시 계산해야 합니다. 이 글의 가격 숫자는 선택 방향을 잡기 위한 기준선이고, 최종 견적은 각 서비스의 최신 문서에서 확인하는 편이 안전합니다.