엣지 & 서버리스 데이터베이스 2026 완벽 가이드 - Cloudflare D1 · Hyperdrive · Turso · PlanetScale · Neon · Supabase · Convex · Fauna · Xata 심층 분석

"2026년의 데이터베이스는 더 이상 한 곳에 있지 않다. 사용자 옆에 살거나, 0으로 자거나, 둘 다 한다." — Cloudflare Developer Day 키노트, 2025년 4월

엣지(Edge) 컴퓨팅과 서버리스(Serverless) 워크로드가 폭발적으로 늘어나면서, 데이터베이스는 더 이상 단일 리전 RDS 인스턴스만으로는 부족한 시대가 되었습니다. Cloudflare Workers는 전 세계 330개 도시에서 V8 isolate를 5ms 안에 부팅하지만, 정작 데이터를 가지러 us-east-1로 가는 왕복 시간이 250ms — 엣지에 함수를 두는 의미가 사라집니다. 이 격차를 메우기 위해 2020년대 초반부터 "엣지 데이터베이스"라는 새 카테고리가 만들어졌고, 2026년 현재 그 생태계는 합병, 폐업, 재편을 거치며 완전히 새로운 지형을 그리고 있습니다.

이 글에서는 Cloudflare D1, Hyperdrive, Workers KV, Durable Objects, R2, Queues 같은 Cloudflare 스택부터 Turso(libSQL), PlanetScale(Vitess), Neon, Supabase, Convex, Fauna, Xata, Tigris, Upstash, Momento, Vercel Postgres, MongoDB Atlas Serverless, DynamoDB, Aurora Serverless v2, CockroachDB Serverless, Spanner, Cosmos DB for PostgreSQL까지 — 2026년 5월 기준 살아남은 모든 주요 제품을 한 글로 정리합니다.

1. 2026년 엣지·서버리스 DB 지도 — 다섯 개의 좌표계

엣지·서버리스 DB는 두 축으로 분류하면 가장 깔끔합니다. 데이터 모델(SQL / KV / Document / Reactive) 과 분산 전략(엣지 레플리카 / 단일 리전 자동확장 / 글로벌 멀티 리전).

선택의 첫 번째 분기점은 항상 "내 워크로드가 읽기 위주인가, 쓰기 위주인가, 글로벌인가, 리전 한정인가"입니다. 읽기 위주 글로벌이면 Turso·D1·Hyperdrive가 최적, 쓰기 위주 단일 리전이면 Neon·Supabase·Aurora가 최적, 강한 일관성이 필요한 글로벌이면 Spanner·CockroachDB, 실시간 구독이 필요하면 Convex입니다.

2. 엣지 데이터베이스란 무엇인가 — 두 가지 정의

"엣지 데이터베이스"는 2020년 이후 만들어진 신생 용어라 정의가 통일되어 있지 않습니다. 2026년 시점에서 시장이 정착시킨 두 가지 의미가 있습니다.

좁은 의미 — 엣지 레플리카(Edge Replica): 사용자에 가까운 엣지 PoP에 읽기 전용 레플리카를 두고, 쓰기는 단일 리전(primary)으로 보내는 모델입니다. Turso의 embedded replica, Cloudflare D1의 globally distributed read replicas(2024년 출시), PlanetScale의 read-only regions이 이 패턴입니다. 읽기 지연이 5–20ms 수준으로 낮아지지만, 쓰기는 여전히 primary까지 왕복합니다.

넓은 의미 — 엣지 런타임 호환(Edge-runtime-compatible): 데이터베이스 자체는 한 곳에 있어도, 엣지 함수(Workers, Vercel Edge, Deno Deploy)의 V8 isolate 환경에서 동작하는 클라이언트를 제공하는 모델입니다. Neon serverless driver, Supabase JS client, PlanetScale serverless driver, Upstash REST API가 이 카테고리입니다. 진정한 의미의 엣지는 아니지만, "Workers에서 Postgres 쓰기"라는 매우 흔한 시나리오를 푸는 핵심 도구입니다.

엣지 런타임의 제약을 이해해야 합니다. Cloudflare Workers와 Vercel Edge Runtime은 Node.js가 아니라 V8 isolate 위에서 돌기 때문에 long-lived TCP 커넥션을 유지할 수 없고, node:net, node:dns도 제한적입니다. 그래서 전통적인 pg 드라이버는 못 쓰고, HTTP/WebSocket 기반 드라이버 가 필수입니다. Neon은 PgBouncer + WebSocket 프록시를 제공하고, PlanetScale은 HTTP 기반 serverless driver를, Upstash는 처음부터 REST API로 시작했습니다.

3. Cloudflare D1 — SQLite on Workers, 2024년 GA

D1은 Cloudflare가 2022년 5월 발표하고 2024년 4월 GA한 SQLite 기반 엣지 데이터베이스입니다. Workers에서 호출할 때 sub-ms 바인딩으로 직접 접근하며, 2025년부터는 전 세계 멀티 리전 읽기 레플리카를 자동으로 배포합니다.

2026년 5월 기준 D1 스펙

D1은 Workers 바인딩으로 직접 호출하기 때문에 Hyperdrive 같은 별도 풀러가 필요 없고, SQLite의 모든 표준 SQL(JOIN, CTE, 윈도우 함수, FTS5)을 지원합니다. 단점은 SQLite의 단일 쓰기 락 — 동시 쓰기 워크로드에서는 큐잉이 일어납니다.

// D1 사용 예시 — Workers
export default {
  async fetch(req: Request, env: { DB: D1Database }) {
    const { results } = await env.DB
      .prepare('SELECT id, name FROM users WHERE active = ?')
      .bind(1)
      .all<{ id: number; name: string }>()
    return Response.json(results)
  },
}

대표 사례는 Cloudflare 본인의 1.1.1.1 도메인 등록 서비스, OpenStatus의 모니터링 데이터, Resend의 도메인/메일 메타데이터 저장입니다. 한국에서는 토스 일부 사이드 프로젝트, NAVER WHALE의 동기화 베타에서 사용 흔적이 보고되었습니다.

4. Cloudflare Hyperdrive — Postgres/MySQL 엣지 가속기

Hyperdrive는 Workers에서 외부 Postgres/MySQL을 호출할 때의 두 가지 고질병 — 커넥션 핸드셰이크 비용과 쿼리 결과 캐시 — 을 해결하기 위해 2024년 4월 GA된 서비스입니다. 2025년에 MySQL 지원이 추가되었습니다.

작동 원리는 단순합니다. Workers는 Hyperdrive 바인딩을 호출하고, Hyperdrive가 사용자 가장 가까운 PoP에서 풀링된 커넥션으로 RDB에 쿼리합니다. 추가로 GET 성격의 쿼리는 결과를 캐싱해 다음 호출에 ms 단위로 응답합니다.

가격 (2026.05): Workers Paid 플랜에 포함, 별도 요금 없음. 단 캐시 hit/miss 통계 대시보드 제공.

지연 개선 사례 — Cloudflare 자체 벤치마크에서 us-east-1 Neon에 워싱턴에서 직접 접속: 35ms p50, 시드니에서 직접 접속: 280ms p50. Hyperdrive 경유 — 워싱턴: 6ms (캐시 hit) / 38ms (miss), 시드니: 12ms (hit) / 285ms (miss). 즉 캐시 hit이 나는 read 쿼리에서 엄청난 효과, miss시는 직접 접속과 비슷.

// Hyperdrive 사용 — Workers + Postgres
import { Client } from 'pg'

export default {
  async fetch(req: Request, env: { HYPERDRIVE: Hyperdrive }) {
    const client = new Client({ connectionString: env.HYPERDRIVE.connectionString })
    await client.connect()
    const { rows } = await client.query('SELECT * FROM products LIMIT 10')
    await client.end()
    return Response.json(rows)
  },
}

Hyperdrive는 D1의 대체가 아니라 D1과 함께 쓰는 도구입니다. D1이 어울리는 워크로드(서비스 메타데이터, 사용자 프로필)는 D1, 큰 RDB가 필요한 워크로드(트랜잭션 시스템, 검색)는 Hyperdrive 경유 외부 Postgres라는 조합이 일반적입니다.

5. Workers KV, R2, Queues, Durable Objects — Cloudflare 스택의 동반자

Cloudflare 데이터 스택은 D1 외에도 네 개의 핵심 컴포넌트를 가집니다.

Workers KV — 글로벌 분산 키-값 저장소. 쓰기는 ~60초 안에 모든 PoP로 전파되는 eventually consistent 모델. 값 크기 25MB, 키 512B 한도. 가격: 10M 읽기 무료 후 1M당 $0.50, 1M 쓰기 무료 후 1M당$5.00. 세션 토큰, 피처 플래그, A/B 테스트 변형 같은 "한 번 쓰고 자주 읽는" 데이터에 최적.

Cloudflare R2 — S3 호환 객체 저장소. 트래픽 egress 무료가 최대 차별점. 가격: 저장 $0.015/GB/월, Class A(쓰기)$4.50/1M 요청, Class B(읽기) $0.36/1M 요청. AWS S3에 비해 egress 0원으로 미디어·로그·백업·정적 자산 호스팅 비용을 80% 이상 줄이는 사례가 흔합니다.

Cloudflare Queues — 메시지 큐. 60초 안에 모든 메시지 배달 보장, 최대 7일 보관. 가격: 1M 작업 $0.40. EventBridge·SQS의 엣지 친화 대체재.

Durable Objects (DO) — 단일 인스턴스에 강한 일관성을 제공하는 stateful primitive. 2025년 SQLite 기반 storage backend로 전환되어 사실상 "사용자별 SQLite DB"가 가능해졌습니다. 채팅방, 라이브 협업 문서, 게임 룸, 실시간 카운터 같은 패턴에 최적. 가격: $5/M 요청 +$12.50/GB-월. Cloudflare 본인의 회의 제품 Realtime, Linear의 라이브 커서, Notion 라이브 블록이 DO를 사용한다고 알려졌습니다.

이 다섯 서비스(D1, KV, R2, Queues, DO)는 모두 Workers 바인딩으로 호출되며 추가 인증/DNS 왕복 없이 sub-ms로 접근 가능합니다. 이것이 Cloudflare 스택의 가장 큰 강점입니다.

6. Turso — libSQL과 임베디드 레플리카의 발명

Turso는 2022년 Glauber Costa 등이 설립한 회사로, SQLite를 fork해 만든 libSQL을 핵심으로 합니다. 2024년 가장 주목할 만한 혁신은 임베디드 레플리카(Embedded Replica) — 앱 프로세스 안에 SQLite 파일을 두고, 백그라운드에서 primary와 동기화하는 모델입니다.

임베디드 레플리카의 효과: 일반 쿼리는 메모리/로컬 SQLite에서 sub-ms 응답, 데이터는 5–60초 간격으로 primary에서 pull. Vercel Edge·Bun·Node 어디서든 동작. 읽기는 로컬 디스크 수준의 지연(0.1ms), 쓰기는 primary 왕복.

2026년 5월 Turso 스펙

Turso는 2025년 Mooncake Labs를 인수해 libSQL Server 분산 빌드에 집중했고, 2026년에는 멀티 마스터 라이트 어센크(Sync Engine)를 베타로 발표했습니다. Convex, Linear, Cal.com 같은 회사가 사용자별 DB 분리(per-user database) 패턴으로 Turso를 채택했습니다.

// Turso 임베디드 레플리카 사용
import { createClient } from '@libsql/client'

const db = createClient({
  url: 'file:local.db',                // 로컬 SQLite 파일
  syncUrl: 'libsql://my-db.turso.io',  // primary URL
  authToken: process.env.TURSO_AUTH_TOKEN!,
  syncInterval: 60,                     // 60초마다 sync
})

// 읽기 — sub-ms (로컬)
const users = await db.execute('SELECT * FROM users LIMIT 10')

// 쓰기 — 즉시 로컬 반영 + 백그라운드로 primary 전송
await db.execute({ sql: 'INSERT INTO logs (msg) VALUES (?)', args: ['hi'] })

7. LiteFS (Fly.io) — SQLite를 분산하는 또 다른 방법

LiteFS는 Fly.io가 2022년 발표한 FUSE 기반 SQLite 복제 솔루션입니다. SQLite WAL을 가로채 모든 트랜잭션을 다른 노드로 streamming하는 방식으로, "쓰기는 primary, 읽기는 어느 노드에서나"를 지원합니다.

2024년 Fly가 LiteFS Cloud를 종료하면서 호스팅 옵션은 사라졌지만, 오픈소스 LiteFS 자체는 계속 유지 되고 있고, Fly Apps + LiteFS 조합으로 직접 운영하는 사례는 여전합니다. WAL 기반이라 트랜잭션 일관성이 강하다는 점이 Turso의 sync 방식과 다른 차별점입니다.

대표 사례는 Fly.io 본인의 인프라, Aha! 일부 모듈, Crisp(고객 지원) 일부 워크로드 등입니다. 2026년에는 새 채택은 거의 멈췄고, Turso·D1이 점유율을 거의 다 가져갔습니다.

8. PlanetScale — Vitess와 무중단 스키마 변경

PlanetScale은 YouTube가 만든 Vitess(MySQL 샤딩 프레임워크)를 SaaS화한 회사로, 2024년까지 모던 스택의 사실상 표준이었습니다. 가장 큰 차별점은 branching(Git처럼 DB 분기) 과 deploy request(스키마 변경을 PR처럼 리뷰) 두 가지입니다.

2024년 4월 PlanetScale은 Hobby 무료 티어를 종료 했고, 이는 한국·일본 개발자 커뮤니티에서 큰 충격이었습니다. 2025년 11월 PlanetScale은 Vitess 유지보수에 집중하는 방향으로 노선을 재정의했고, 2026년 현재 비즈니스의 70% 이상이 Enterprise Vitess 호스팅에서 나옵니다.

2026.05 PlanetScale 플랜

PlanetScale은 진정한 "엣지 DB"라기보다 단일 리전 MySQL을 매우 잘 운영하는 SaaS입니다. Read-only 리전(US/EU/AP) 옵션으로 글로벌 읽기 지연을 줄일 수 있고, HTTP serverless driver(@planetscale/database)로 Workers·Vercel Edge에서도 호출 가능합니다.

대표 사례는 Vercel(자체 데이터), Cash App, Square, Notion(일부 워크로드), GitHub Copilot 일부 메타데이터입니다. 한국에서는 토스의 일부 분석 워크로드와 당근마켓의 검색 메타데이터에서 사용 흔적이 보고됩니다.

9. Neon — 서버리스 Postgres와 분기, Databricks 인수

Neon은 2021년 Heikki Linnakangas(Postgres 핵심 커미터)가 설립한 서버리스 Postgres 회사로, storage와 compute를 분리 한 신박한 아키텍처가 핵심입니다. Compute는 0으로 잘 수 있고 5초 만에 깨어나고, storage는 S3 기반 페이지 서버로 무한 확장됩니다.

가장 강력한 기능은 DB branching — Git 브랜치처럼 DB를 CoW(copy-on-write)로 복제해 PR마다 격리된 DB를 갖는 패턴. CI/CD 파이프라인에서 매 PR마다 1초 만에 새 브랜치를 만들고, 머지 시 삭제하는 방식이 표준이 되었습니다.

2025년 5월 Databricks가 Neon을 약 $10억에 인수했고, 2026년 현재 Databricks Lakebase의 OLTP 백엔드로 통합되었습니다. 인수 이후에도 Neon 자체 서비스는 그대로 유지되며 무료 티어도 보존되었습니다.

2026.05 Neon 플랜

Neon은 Vercel Postgres의 백엔드이기도 합니다 — Vercel은 2023년부터 Neon과 파트너십을 맺고 Vercel Postgres라는 이름으로 wrapping해 판매해왔습니다. 2025년 Databricks 인수 후에도 이 파트너십은 유지되고 있습니다.

10. Supabase — Postgres + Auth + Storage + Realtime + Edge Functions

Supabase는 2020년 Paul Copplestone이 설립한 "오픈소스 Firebase" 포지셔닝의 BaaS입니다. Postgres + GoTrue(Auth) + Storage(S3 wrapper) + Realtime(Postgres logical replication) + Edge Functions(Deno) + Vector(pgvector)를 한 플랫폼에 묶었습니다.

2026년 가장 큰 변화는 Supabase Branching GA(2024년 10월)와 Supabase Edge Runtime 2.0(2025년 9월) 두 가지입니다. Branching은 Neon 스타일의 DB 분기, Edge Runtime 2.0은 Deno 1.46 기반에서 Deno 2.x로 업그레이드되며 cold start가 50ms 미만으로 줄었습니다.

2026.05 Supabase 플랜

Supabase의 강점은 "프로덕트 한 개에 필요한 모든 것이 한 SDK에 있다"는 점입니다. Auth, RLS(Row Level Security) 정책, 파일 업로드, 실시간 구독을 같은 토큰으로 처리할 수 있어 풀스택 개발 속도가 빠릅니다. 약점은 PostgreSQL과 너무 결합되어 있어 비-Postgres 백엔드로 이동이 어렵다는 점입니다.

대표 사례는 Mozilla AI, Resend, Trigger.dev, Cal.com, Pieter Levels의 여러 인디 프로덕트입니다. 한국에서는 당근마켓 사이드 프로젝트, 토스 페이먼츠 일부 개발자 도구에서 사용됩니다.

11. Convex — Reactive 풀스택 서버리스 DB

Convex는 2022년 Jamie Turner(전 Dropbox 엔지니어링 디렉터)가 설립한 "풀스택 reactive DB"입니다. 자체 트랜잭션 DB + 자체 query engine + 자체 JavaScript runtime으로 묶은 단일 플랫폼이며, 클라이언트가 query를 구독하면 데이터가 바뀔 때마다 자동으로 push되는 모델입니다.

기술적으로 가장 흥미로운 점은 결정성(determinism) — 모든 query/mutation 함수는 JavaScript지만 syscall이 막힌 V8 isolate에서 실행되어 같은 입력 → 같은 출력이 보장되고, transaction 충돌 시 자동 재시도가 가능합니다.

// Convex query/mutation 예시
import { query, mutation } from './_generated/server'
import { v } from 'convex/values'

export const listPosts = query({
  args: { authorId: v.id('users') },
  handler: async (ctx, { authorId }) => {
    return await ctx.db
      .query('posts')
      .withIndex('by_author', (q) => q.eq('authorId', authorId))
      .collect()
  },
})

export const createPost = mutation({
  args: { title: v.string(), body: v.string() },
  handler: async (ctx, args) => {
    return await ctx.db.insert('posts', args)
  },
})

2026.05 Convex 플랜

Convex의 단점은 lock-in이 강하다는 것 — 자체 query 언어와 자체 schema 시스템을 쓰기 때문에 다른 DB로 마이그레이션이 어렵습니다. 대신 풀스택 인디 개발이나 빠른 프로토타이핑에는 무적입니다. 대표 사례는 a16z 투자 포트폴리오 다수, Cursor 일부 기능, MoonshotAI(2025년 일부 워크로드 이전).

12. Fauna — 2025년 5월 서비스 종료

Fauna는 2012년 Evan Weaver와 Matt Freels(전 Twitter 엔지니어)가 설립한 분산 NoSQL DB로, Calvin 합의 알고리즘과 FQL(자체 query 언어), 멀티 리전 강한 일관성을 내세웠습니다. 2010년대 후반 가장 야심찬 분산 DB 프로젝트 중 하나였습니다.

그러나 2025년 3월 Fauna는 2025년 5월 30일 서비스 종료를 공지했습니다. 이유는 공식적으로 "지속 가능한 비즈니스 모델 구축 실패". 고객들에게는 90일 데이터 마이그레이션 기간이 주어졌고, Convex, MongoDB Atlas, Couchbase Capella를 권장 대체재로 안내했습니다.

Fauna의 종료는 2020년대 초중반 "야심찬 분산 NoSQL" 카테고리의 한계를 보여주는 상징적 사건이 되었습니다. 자체 query 언어(FQL)의 학습 곡선, GraphQL 인터페이스의 완성도 부족, AWS DynamoDB와 Spanner 사이에서의 포지셔닝 실패가 누적된 결과입니다.

마이그레이션 경로별 권고는 일반적으로 — 강한 일관성과 분산 SQL이 필요하면 CockroachDB나 Spanner, 풀스택 reactive가 필요하면 Convex, 키-값/document면 DynamoDB나 MongoDB Atlas입니다.

13. Xata — 2025년 12월 신규 가입 종료

Xata는 2022년 Monica Sarbu(Elastic 출신)가 설립한 "Postgres + 검색 + 분석" 하이브리드 BaaS입니다. Postgres와 ElasticSearch를 한 스키마로 묶은 신박한 모델로, Vercel·SaaS 스타트업 사이에서 잠깐 인기를 끌었습니다.

2024년 Xata는 PostgreSQL을 100% 표준으로 만들기 위해 OrioleDB 기반으로 백엔드를 재구축했고, 2025년 12월 갑작스럽게 신규 가입 종료를 공지했습니다. 기존 고객은 2026년 말까지 운영을 보장받으며, 회사는 OrioleDB와 pg-roll(zero-downtime migration 도구) 같은 오픈소스 프로젝트로 피벗했습니다.

OrioleDB는 Postgres의 storage engine을 cloud-native(분리된 storage)로 재작성한 프로젝트로, Supabase가 2025년 OrioleDB를 인수해 핵심 엔지니어들을 영입했습니다. 즉 Xata의 기술 자산은 Supabase로 흡수되었고, 2026년의 Supabase Postgres는 OrioleDB 기반 옵션을 베타로 제공합니다.

14. Tigris Data — 글로벌 분산 객체 + DB

Tigris Data는 2022년 Ovais Tariq, Yevgeniy Firsov(전 Uber 분산 시스템) 등이 설립한 회사로, 2024년부터 S3 호환 글로벌 객체 저장소로 포지셔닝을 재정의했습니다. 처음에는 document DB로 시작했으나, AI 워크로드의 객체 저장소 수요를 보고 피벗한 사례입니다.

2026년 Tigris의 핵심 가치는 자동 글로벌 복제 — 객체를 어디서 쓰든 자동으로 사용자 가까운 리전에 복제, egress 무료, S3 호환 API. AI 모델 체크포인트, 학습 데이터셋, 추론 결과 캐시 같은 워크로드에 최적입니다. 가격: 저장 $0.02/GB/월, 클래스 A 요청$0.005/1K, egress $0/GB.

Cloudflare R2와 비교하면 — R2는 단일 리전 저장 + 글로벌 캐시, Tigris는 진정한 글로벌 복제. R2가 egress 무료에서 시작했다면 Tigris는 글로벌 복제까지 무료입니다. 대표 사례는 Lambda Labs(AI GPU 클라우드), Modal Labs 일부 워크로드, several Y Combinator AI 스타트업.

15. Upstash — Redis · Kafka · QStash · Vector 서버리스

Upstash는 2020년 Mehmet Dogan(전 AWS)이 설립한 회사로, "0으로 자고 요청당 과금되는 서버리스 Redis"라는 정체성으로 시작했습니다. 2026년 현재 라인업은 다음과 같습니다.

Upstash Redis — Redis 7.x 호환, HTTP + WebSocket API, 글로벌 복제 가능. 가격: 요청당 $0.20/100K. Workers·Vercel Edge에서 첫 줄로 들어가는 캐시·세션·rate limit 도구.

Upstash Vector — 2024년 발표된 벡터 DB. pgvector·Pinecone 대안. 가격: 요청당 $0.40/100K, 저장$0.25/GB-월.

Upstash QStash — HTTP 기반 메시지 큐 / 스케줄러. Cron + 재시도 + 지수 백오프 + 서명 검증을 한 SaaS로. 가격: $1/100K 메시지.

Upstash Kafka — 2024년 후반 운영 종료. Upstash는 Kafka 라인을 정리하고 Redis·Vector·QStash 세 라인에 집중.

Upstash의 큰 장점은 0 fixed cost — 요청이 없으면 한 푼도 안 냅니다. 사이드 프로젝트, indiehackers, 트래픽 변동 큰 SaaS의 캐시·rate limit 레이어로 거의 사실상 표준이 됐습니다. 대표 사례는 Vercel KV의 백엔드(2024년 종료, 현재는 자체 + Redis Cloud로 이전), Trigger.dev, Resend, Linear 일부 워크로드.

16. Vercel Postgres, KV, Blob, Edge Config — 파트너십의 묶음

Vercel은 2023년 Vercel Storage라는 우산 아래 4개 제품을 발표했습니다 — 모두 외부 파트너의 wrapping입니다.

2026년 Vercel은 데이터 사업을 정리하는 방향으로 노선을 명확히 했습니다. 자체 데이터 인프라를 구축하지 않고, Neon·Upstash·MongoDB 같은 파트너의 wrapper로 위치하며 개발자 경험에 집중합니다. 청구는 Vercel 한 곳으로 모이고, dashboard도 통합되지만, 백엔드 자체는 파트너 인프라입니다.

이는 데이터 카테고리에서 Vercel의 명확한 자기 평가입니다 — "우리는 DB를 만드는 회사가 아니라, 프런트엔드/엣지 함수를 운영하는 회사" — 그리고 데이터는 외부와 묶어서 패키지로 판매. Cloudflare가 D1·R2·KV를 직접 만든 것과 정반대 전략입니다.

17. MongoDB Atlas Serverless — Document의 서버리스

MongoDB Atlas Serverless는 2021년 발표되고 2022년 GA된 서버리스 MongoDB 옵션입니다. 0으로 자지는 않지만, 요청당/저장당 가격으로 청구되고 capacity는 자동 확장됩니다.

2026년 MongoDB Atlas의 핵심 변화는 Atlas Vector Search GA(2024년)와 Atlas Search Nodes(2025년) 두 가지입니다. Vector Search는 hybrid search(키워드 + 벡터)를 지원하며 RAG 백엔드로 채택이 늘었고, Search Nodes는 검색 워크로드를 main cluster와 분리합니다.

가격: 읽기 처리 단위(RPU) $0.10/M, 쓰기 처리 단위(WPU)$1.25/M, 저장 $0.25/GB-월. M0 무료 티어는 sandbox용으로 유지.

MongoDB Atlas Serverless의 강점은 document 모델 + 강한 일관성 + 트랜잭션. 약점은 V8 isolate 환경에서 직접 호출이 어렵다는 점 — Atlas Data API(HTTP) 또는 Atlas App Services(공식 wrapper) 경유 필요. 대표 사례는 Adobe, eBay, Lyft, Forbes, Toyota Connected 등 대기업 다수.

18. AWS DynamoDB & DynamoDB Streams — 클라우드 KV의 최강자

DynamoDB는 2012년 출시되어 14년째 굳건한 AWS의 키-값/document DB입니다. 2026년 시점에서 가장 큰 변화는 DynamoDB Standard-IA(infrequent access, 저장비 60% 인하)와 PartiQL의 안정화, 2024년 Global Tables 멀티 active-active GA입니다.

가격 모델은 두 가지 — On-demand(요청당 $1.25/M write,$0.25/M read, 저장 $0.25/GB-월) 또는 Provisioned(WCU·RCU 예약, 더 저렴하지만 capacity 관리 필요). 2024년 11월 On-demand 가격이 평균 50% 인하되어 다시 매력적인 옵션이 됐습니다.

DynamoDB는 진정한 의미의 엣지 DB는 아니지만, 단일 리전에서 sub-10ms p99로 응답하고 글로벌 테이블로 멀티 리전 active-active도 지원합니다. 한국의 Coupang은 핵심 주문/배송 메타데이터에 DynamoDB를 광범위하게 사용하며(Coupang 엔지니어링 블로그 다수), 일본 Mercari는 거래 메타데이터와 알림 큐에 DynamoDB + Aurora 조합을 씁니다.

// DynamoDB Workers·Edge에서 호출
import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb'

const client = new DynamoDBClient({
  region: 'ap-northeast-2',
  credentials: { accessKeyId: env.AWS_KEY, secretAccessKey: env.AWS_SECRET },
})

const res = await client.send(new GetItemCommand({
  TableName: 'users',
  Key: { id: { S: 'u-1' } },
}))

19. Aurora Serverless v2 — Postgres·MySQL의 자동 확장

Aurora Serverless v2는 2022년 GA된 RDS Aurora의 자동 확장 옵션입니다. v1과 달리 0으로 자지는 못하지만(최소 0.5 ACU), 0.5초 단위로 ACU를 조정해 트래픽 변동에 즉시 대응합니다. 2024년 8월부터는 Aurora Serverless v2 가 0으로 자는 옵션 이 추가되어 진정한 서버리스가 됐습니다.

가격: ACU(Aurora Capacity Unit, 약 2GB RAM)당 $0.12/시간. 0으로 자는 옵션은 cold start 약 15초.

Aurora는 진정한 의미의 엣지 DB는 아니지만, RDS의 모든 표준 SQL과 트랜잭션을 그대로 쓰면서 capacity 관리에서 해방된다는 장점이 있습니다. 한국의 NHN Cloud, 카카오엔터프라이즈 등도 Aurora 호환 서비스를 운영합니다.

대표 사례는 Slack, Robinhood, Samsung Electronics, Roblox 같은 대규모 SaaS의 운영 DB로 광범위하게 채택되었으며, 2026년에도 단일 리전 트랜잭션 워크로드의 사실상 표준입니다.

20. CockroachDB Serverless — 분산 SQL의 서버리스

CockroachDB는 2015년 Spencer Kimball(전 Google, Spanner 영향)이 만든 분산 SQL DB로, Postgres wire protocol 호환에 멀티 리전 강한 일관성을 제공합니다. CockroachDB Serverless는 2021년 발표되고 2022년 GA됐습니다.

2026.05 CockroachDB Serverless 가격

CockroachDB의 강점은 진정한 멀티 리전 active-active — 어느 리전에서 쓰든 다른 리전에 강한 일관성으로 복제되며, 한 리전이 죽어도 자동 failover. 약점은 비용 — 같은 워크로드 기준 단일 리전 Aurora 대비 2–3배 비싼 경우가 흔합니다.

2024년 CockroachDB는 무료 티어를 정리하고 가격을 인상해 한국·일본 인디 개발자 사이에서는 호불호가 갈렸습니다. 대신 글로벌 fintech, 다국적 SaaS, 게임 백엔드 같은 워크로드에서는 거의 대체 불가입니다. 대표 사례는 DoorDash, Netflix(일부), Bose, Form3(영국 fintech), Shipt.

21. Spanner — Google의 글로벌 SQL과 PostgreSQL 인터페이스

Spanner는 2017년 GCP에서 공개된 Google의 글로벌 분산 SQL DB로, TrueTime API(원자 시계 기반 시간 동기화)와 Paxos 합의로 멀티 리전 강한 일관성을 제공합니다. 14년간 Google 내부에서 검증된 시스템이며, 핵심 광고/결제 시스템이 그 위에서 돕니다.

2026년 Spanner의 가장 큰 변화는 PostgreSQL Interface GA(2023)와 Spanner Graph(2025년 출시) 두 가지입니다. PostgreSQL Interface는 Spanner를 처음부터 ANSI SQL + Postgres 방언으로 사용할 수 있게 했고, Spanner Graph는 한 시스템에서 SQL + graph 쿼리를 둘 다 지원합니다.

가격: 노드당 $0.90/시간(US 리전, 2024년 GA된 처리 단위 기준 옵션은 더 세분화). 멀티 리전은 노드당 약 3배.

Spanner의 강점은 검증된 글로벌 강한 일관성과 무한 확장. 약점은 비용과 GCP lock-in. 한국의 카카오뱅크가 일부 글로벌 워크로드에서 Spanner 도입을 검토 중이라는 보고가 있고, 일본의 LINE Yahoo가 광고 인벤토리에서 Spanner를 운영합니다.

22. YugabyteDB · Cosmos for PostgreSQL · OrioleDB — Postgres 호환 분산 DB들

CockroachDB 외에도 Postgres 호환 분산 DB는 여러 개가 경쟁합니다.

YugabyteDB — 2016년 Karthik Ranganathan(전 Facebook Apache Cassandra)가 만든 분산 DB. PostgreSQL 11 호환에 멀티 리전 강한 일관성. 2024년 Yugabyte Cloud 무료 sandbox 종료, 현재 14일 무료 trial만 제공. 강점은 Cassandra 출신 분산 storage layer의 검증, 약점은 Postgres 호환성이 CockroachDB보다 살짝 약합니다.

Azure Cosmos DB for PostgreSQL — 2022년 Microsoft가 인수한 Citus를 Cosmos DB 우산에 통합한 제품. 분산 Postgres 샤딩과 hyperscale을 강조. 가격: $0.27/vCPU/시간부터 시작. Microsoft 스택 사용자에게 자연스러운 선택.

OrioleDB — Postgres의 storage engine을 cloud-native(분리된 storage)로 재작성한 오픈소스 확장. 2025년 Supabase가 인수해 핵심 엔지니어 영입. 2026년 현재 Supabase Postgres 옵션으로 베타 제공. heap의 한계(WAL 부하, vacuum 비용)를 우회해 동일 워크로드에서 5–10배 throughput을 보고합니다.

OrioleDB는 진정한 의미의 분산 DB가 아니라 Postgres의 storage layer 개선 인 점이 차별점입니다. 멀티 리전 합의는 여전히 별도의 레이어(Patroni, Hyperdrive 같은 캐시) 필요.

23. Momento — Redis의 진정한 서버리스 대체

Momento는 2022년 Khawaja Shams(전 AWS DynamoDB 리더)가 설립한 회사로, "Redis보다 더 서버리스인 캐시"를 표방합니다. Upstash와 비교하면 — Upstash는 Redis 호환, Momento는 자체 API + Redis API 호환 옵션.

Momento의 차별점은 0 fixed cost + 0 capacity planning. 데이터가 들어오면 자동으로 capacity 확장, 트래픽이 없으면 0. 가격: 데이터 전송 $0.50/GB(읽기·쓰기 결합), 저장 무료.

2024년 Momento는 Momento Topics(Pub/Sub)와 Momento Cache(메인 캐시) 두 라인을 GA했고, 2025년에는 Storage(영속 K/V) 베타를 추가했습니다. 대표 사례는 The Wall Street Journal, Walgreens, Pulpify, AWS의 일부 partner workshop.

Momento와 Upstash 선택은 — Redis API 호환과 자체 클라이언트가 이미 있으면 Upstash, 진정한 0 capacity 관리와 가격 단순성이 필요하면 Momento입니다.

24. Drizzle ORM 0.40 · Prisma 6 — ORM 레이어의 경쟁

엣지·서버리스 DB의 부상은 ORM에도 큰 영향을 줬습니다. 전통적인 Prisma(2020년대 초반 표준)는 Rust 기반 query engine을 별도 프로세스로 띄우는 구조라 V8 isolate에서 직접 못 돌았고, Cloudflare Workers에서 사용이 어려웠습니다.

2022년 등장한 Drizzle ORM은 Pure TypeScript로 query builder를 만들고 모든 드라이버(libsql, postgres-js, mysql2, planetscale, neon serverless)를 지원하면서 빠르게 표준이 됐습니다. 2026년 5월 현재 Drizzle 0.40대는 다음을 지원합니다.

• TypeScript-first schema 정의(SQL DDL 자동 생성)
• D1, Turso, Neon, PlanetScale, Postgres, MySQL, SQLite, AWS Data API, Bun:sqlite
• Drizzle Kit(스키마 마이그레이션 도구), Drizzle Studio(GUI)
• 2025년 12월 Vercel이 인수한 후에도 오픈소스로 유지

Prisma 6(2024년 9월 출시)는 Rust → TypeScript 마이그레이션 을 단행해 V8 isolate에서도 동작하기 시작했습니다. 2026년 Prisma는 아직 일부 driver(D1, Cloudflare Workers)에서 Drizzle만큼 매끄럽지 않지만, schema-first 개발 경험과 풍부한 ecosystem(Prisma Migrate, Prisma Studio, Prisma Pulse)이 강점입니다.

선택은 — Workers·엣지 첫 번째라면 Drizzle, Next.js 표준 + 풍부한 도구가 필요하면 Prisma입니다. 한국·일본 개발 커뮤니티 모두 2024년 이후 Drizzle 점유율이 급격히 늘었습니다.

25. 엣지 DB가 어울리는 워크로드 / 어울리지 않는 워크로드

엣지·서버리스 DB는 만능 해결책이 아닙니다. 선택의 핵심 기준은 다음과 같습니다.

어울리는 워크로드

• 읽기 위주 글로벌 앱: 블로그, 문서 사이트, 마케팅 페이지, 소셜 피드 캐시 — Turso, D1, Hyperdrive
• 단일 리전 OLTP: SaaS 대시보드, 결제 트랜잭션, 사용자 프로필 — Neon, Supabase, Aurora Serverless
• 풀스택 reactive: 채팅, 라이브 협업, 게임 룸 — Convex, Supabase Realtime, Durable Objects
• 글로벌 캐시 / rate limit: Workers KV, Upstash Redis, Momento
• 객체 저장 + CDN: R2, Tigris, Blob
• AI 임베딩 / 벡터: Upstash Vector, MongoDB Atlas Vector, pgvector on Neon/Supabase

어울리지 않는 워크로드

• 고쓰기 OLTP: 거래소, 광고 클릭 로그, IoT 텔레메트리 — 차라리 Aurora·Bigtable·ClickHouse
• 복잡 트랜잭션 + 외래 키 제약 + 다단계 JOIN: 분산 SQL은 모두 단일 리전 RDB보다 느림 — RDS·Aurora가 정답
• PB 단위 분석: BigQuery, Snowflake, ClickHouse, Databricks
• 강한 일관성 + 글로벌: 비싸도 Spanner·CockroachDB가 사실상 유일

엔지니어링 결정의 핵심은 "내 워크로드의 read/write 비율, 글로벌 여부, 일관성 요구사항"입니다. 90% 이상의 SaaS는 단일 리전 Postgres + 글로벌 캐시(KV) 조합으로 충분하고, 글로벌 강한 일관성이 진짜로 필요한 워크로드는 손에 꼽힙니다.

26. 가격 비교 — 같은 워크로드, 다른 청구서

가상의 워크로드 — 월 10M API 요청, 평균 read 5회 + write 1회 per 요청, 저장 50GB, 글로벌 사용자.

같은 워크로드라도 청구서가 2–5배 차이가 나며, 트래픽 변동 폭이 크면 0으로 자는 옵션(Neon·Aurora v2) 이 유리하고, 트래픽이 일정하면 정액(Supabase Pro·Turso Starter) 이 유리합니다. 모든 가격은 2026년 5월 기준이며 무료 티어 한도와 별도 단가가 적용될 수 있어 실제 청구서는 다를 수 있습니다.

27. 한국 도입 사례 — Coupang · 토스 · 당근 · NAVER · NHN Cloud

한국 주요 회사들의 2026년 시점 데이터베이스 선택은 다음과 같습니다.

Coupang — DynamoDB를 핵심 주문/배송 메타데이터에 광범위하게 사용. AWS 환경 + JVM 스택의 일관성이 결정 요인. Aurora MySQL은 거의 모든 상거래 마스터 데이터에 사용. ElastiCache Redis는 세션·실시간 카운터.

토스 (Toss) — 핵심 결제는 자체 운영 Postgres + MySQL 클러스터. 일부 분석·실험 워크로드에 PlanetScale, BigQuery. 토스증권·페이먼츠 등 자회사가 개별 stack 운영. 모든 사이드/실험 도구에 Supabase·Neon 사용 보고.

당근마켓 — Postgres + Redis 코어. 검색 메타데이터에 PlanetScale, 글로벌 캐시에 Cloudflare KV 일부 검토. AI·벡터 워크로드에 pgvector + Pinecone.

NAVER · NAVER Cloud — Cubrid(자체 DB) + MySQL + Postgres. Cloud DB 사업으로 PostgreSQL, MySQL, MongoDB, Redis 호스팅 제공. 검색·광고는 자체 분산 시스템.

NHN Cloud — RDS 호환(Postgres·MySQL) + 자체 분산 시스템(Pinpoint, Dooray). 게임 백엔드용 Game Cloud DB.

한국 회사들은 일반적으로 AWS 의존도가 매우 높고(DynamoDB, Aurora, ElastiCache, OpenSearch), 엣지 DB는 사이드 프로젝트와 신규 SaaS 스타트업에서 빠르게 채택되는 양상입니다.

28. 일본 도입 사례 — Mercari · LINE Yahoo · CyberAgent · DeNA

일본 주요 회사들의 데이터베이스 선택입니다.

Mercari — 핵심 거래에 Aurora MySQL + DynamoDB. 알림·큐 워크로드에 SQS + Lambda. 검색은 자체 ElasticSearch. AI 추천에 자체 모델 + DynamoDB로 캐시.

LINE Yahoo (LY Corporation) — 메시징은 자체 분산 시스템(자체 NoSQL + Redis 클러스터). 광고 인벤토리·집계에 Spanner 운영(GCP 일본 리전), Yahoo! 광고 시스템에는 ClickHouse 광범위 사용.

CyberAgent — AbemaTV 백엔드에 CockroachDB와 Aurora 혼용. 광고 입찰 시스템에는 자체 분산 KV + DynamoDB. 게임 자회사들은 각자 다른 stack.

DeNA — 모바일 게임 백엔드에 Aurora + DynamoDB. 일부 횡축 분산 워크로드는 자체 Cassandra 클러스터. AI 추천에 BigQuery + Vertex AI.

Smart News — 뉴스 추천에 DynamoDB + ElastiCache Redis + S3 + Athena. 컨텐츠 메타데이터에 Aurora.

일본 회사들은 한국과 비슷하게 AWS·GCP 양쪽 멀티 클라우드 채택이 많고, 특히 광고·미디어 같은 글로벌 워크로드에서 Spanner·CockroachDB 도입이 한국보다 적극적입니다.

29. 마이그레이션 시나리오 — Fauna에서 Convex/DynamoDB로

Fauna 종료를 계기로 2025년 가장 흔히 발생한 마이그레이션 시나리오는 다음과 같습니다.

Fauna → Convex: 풀스택 reactive 앱이 주 사용 사례였다면 자연스러운 선택. FQL → Convex TypeScript 함수, GraphQL 의존이 있었다면 Apollo Client 그대로, 실시간 구독은 Convex live query로 대체.

Fauna → DynamoDB: 키-값/document 워크로드라면 DynamoDB가 비용·성능 모두 우위. 데이터 모델 재설계(NoSQL access pattern 기반) 필요. 글로벌 active-active가 필요하면 Global Tables.

Fauna → MongoDB Atlas Serverless: document 모델 그대로 유지, FQL → MongoDB aggregation pipeline 변환. 가장 단순한 1:1 대응이 가능한 경로.

Fauna → CockroachDB / Spanner: 강한 일관성 + 글로벌이 핵심이었다면. 다만 SQL로의 패러다임 전환 비용이 큼.

PlanetScale 무료 티어 종료 후 가장 흔한 마이그레이션 경로는 PlanetScale → Neon / Supabase(Postgres) 또는 PlanetScale → Aurora Serverless v2(MySQL 유지)였습니다.

30. 2027년 이후 전망 — AI 워크로드와 OrioleDB가 바꿀 것

2026년 시점에서 향후 2–3년 트렌드를 예측하면 다음과 같습니다.

AI 워크로드의 데이터 요구사항이 카테고리를 다시 정의 — 벡터 DB(Pinecone, Weaviate, Qdrant) 와 pgvector 통합 Postgres(Supabase, Neon) 사이 경쟁 심화. 멀티모달 임베딩, 그래프 RAG, 임베디드 검색을 한 DB에 모아넣는 흐름.

OrioleDB와 cloud-native Postgres storage engine 표준화 — Supabase가 인수한 OrioleDB가 2027년 stable이 되면, 전통적인 Postgres heap의 한계(WAL 부하, vacuum, freezing)를 벗어난 새 세대 Postgres가 표준이 될 가능성.

엣지 DB의 쓰기 분산 본격화 — Turso, D1이 멀티 마스터 쓰기를 베타로 발표하고 있고, 2027년에는 진정한 active-active 엣지 DB가 나올 가능성. CRDT 기반 sync engine의 일반화.

Database-as-Code의 표준화 — Drizzle Kit, Atlas, Snaplet, Tinybird 같은 도구들이 schema 마이그레이션·테스트 데이터·미리보기 환경을 코드로 다루는 흐름. CI/CD 파이프라인에 DB가 1급 시민으로 통합.

가격 인하 압박 — 무료 티어 정리 (Fauna, Xata, PlanetScale, Yugabyte)는 2024–2025년 트렌드였지만, 2026년부터는 경쟁 격화로 다시 가격 인하 압박. 특히 DynamoDB On-demand 가격 인하(2024.11)가 시발점.

31. 결론 — 워크로드가 모든 것을 결정한다

엣지·서버리스 DB의 세계는 2020년 이후 6년간 폭발적으로 커졌고, 2024–2025년에는 처음으로 카테고리 정리(consolidation)와 폐업(Fauna, Xata, Yugabyte 무료 종료)이 일어났습니다. 2026년 5월 현재 시장은 다음 5개 큰 묶음으로 정착됐습니다.

1. Cloudflare 스택 — D1, Hyperdrive, KV, R2, Queues, DO. Workers 중심 풀스택.
2. Postgres 서버리스 묶음 — Neon, Supabase, Vercel Postgres, Aurora Serverless v2. 가장 큰 시장.
3. 엣지 SQLite — Turso, D1. 글로벌 읽기에 최적.
4. 글로벌 분산 SQL — CockroachDB, Spanner, YugabyteDB. 비싸지만 필수.
5. 풀스택 reactive — Convex, Supabase Realtime. 새 패러다임의 가능성.

엔지니어링 결정의 핵심 질문은 변하지 않습니다 — 읽기 위주인가 쓰기 위주인가, 글로벌인가 리전인가, 강한 일관성이 필요한가, 트래픽 변동이 큰가. 이 네 가지 질문의 답을 정직하게 적어내면 어떤 DB가 어울리는지가 거의 자동으로 결정됩니다.

마지막으로, 2026년의 가장 중요한 교훈 — "엣지 DB"를 도입하기 전에 "내 워크로드가 정말 엣지가 필요한가"를 먼저 물어보십시오. 90% 이상의 SaaS는 단일 리전 Postgres + 글로벌 캐시면 충분합니다. 글로벌 사용자가 있어도 모든 데이터가 글로벌 복제될 필요는 없습니다. 정직한 워크로드 분석이 비용과 복잡성을 줄이는 첫걸음입니다.

References

• Cloudflare D1 공식 문서 — https://developers.cloudflare.com/d1/
• Cloudflare Hyperdrive 공식 문서 — https://developers.cloudflare.com/hyperdrive/
• Cloudflare Workers KV — https://developers.cloudflare.com/kv/
• Cloudflare Durable Objects — https://developers.cloudflare.com/durable-objects/
• Cloudflare R2 — https://developers.cloudflare.com/r2/
• Turso 공식 문서 — https://docs.turso.tech/
• libSQL on GitHub — https://github.com/tursodatabase/libsql
• LiteFS (Fly.io) — https://fly.io/docs/litefs/
• PlanetScale 공식 — https://planetscale.com/docs
• PlanetScale Hobby tier shutdown 공지 — https://planetscale.com/blog/planetscale-forever
• Neon 공식 — https://neon.tech/docs
• Databricks acquires Neon 발표 — https://www.databricks.com/blog/databricks-acquires-neon-helping-developers-deliver-ai-systems
• Supabase 공식 — https://supabase.com/docs
• Supabase acquires OrioleDB — https://supabase.com/blog/orioledb-launch
• Convex 공식 문서 — https://docs.convex.dev/
• Fauna shutdown 공지 — https://fauna.com/blog/announcing-the-end-of-life-of-fauna
• Xata roadmap 변경 공지 — https://xata.io/blog/xata-postgres-saas-shutdown
• Tigris Data — https://www.tigrisdata.com/docs/
• Upstash Redis — https://upstash.com/docs/redis
• Upstash Vector — https://upstash.com/docs/vector
• Momento — https://docs.momentohq.com/
• Vercel Storage — https://vercel.com/docs/storage
• MongoDB Atlas Serverless — https://www.mongodb.com/docs/atlas/manage-clusters/
• DynamoDB pricing reduction 공지 (2024.11) — https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-dynamodb-reduces-prices-on-demand-throughput/
• Aurora Serverless v2 scale to zero — https://aws.amazon.com/blogs/aws/amazon-aurora-serverless-v2-supports-scaling-to-zero-capacity/
• CockroachDB Serverless — https://www.cockroachlabs.com/docs/cockroachcloud/quickstart
• Spanner PostgreSQL interface — https://cloud.google.com/spanner/docs/postgresql-interface
• YugabyteDB — https://docs.yugabyte.com/preview/
• Azure Cosmos DB for PostgreSQL — https://learn.microsoft.com/en-us/azure/cosmos-db/postgresql/
• OrioleDB on GitHub — https://github.com/orioledb/orioledb
• Drizzle ORM — https://orm.drizzle.team/docs/overview
• Prisma 6 release notes — https://www.prisma.io/blog/prisma-6-release
• Standard Webhooks — https://www.standardwebhooks.com/