Cloudflare Hyperdrive: 엣지에서 쓰는 Postgres

Cloudflare Hyperdrive는 아주 구체적이고 전혀 화려하지 않은 문제 때문에 존재합니다. 200개 도시에서 실행되는 Worker가 한 도시에 있는 단일 Postgres 데이터베이스와 대화하면, 그 데이터베이스 바로 옆에 놓인 서버 한 대에서 같은 쿼리를 던질 때보다 느립니다. 조금 느린 정도가 아닙니다. 흔히 몇 배씩 느리며, 그 이유는 쿼리를 어떻게 작성했는지와는 아무 상관이 없습니다.

서버리스 애플리케이션이 굼뜨게 느껴질 때 나오는 반사적인 반응은 쿼리 플래너를 탓하거나 인덱스를 하나 더 추가하는 것입니다. 하지만 리전에 있는 데이터베이스와 대화하는 Workers에서는 쿼리 자체는 대개 멀쩡합니다. 문제는 연결입니다.

Hyperdrive가 실제로 고치는 것: 데이터베이스 연결을 맺는 비용, 그것도 모든 요청마다 다시 지불하는 비용입니다. Postgres 연결은 한 행이 움직이기도 전에 TCP 핸드셰이크와 TLS 협상과 인증 교환을 거쳐야 하고, 그 단계 하나하나가 Worker가 깨어난 위치에서 데이터베이스가 사는 위치까지의 왕복입니다. Hyperdrive는 여러분의 데이터베이스 가까이에 따뜻한 연결을 유지하면서 풀로 묶어 두기 때문에, Worker는 새 연결을 만드는 대신 이미 열려 있는 연결을 빌려 씁니다.

Postgres에 직접 붙은 Worker가 느린 이유

전통적인 애플리케이션 서버는 부팅할 때 연결 풀을 한 번 열어 두고 프로세스가 살아 있는 내내 재사용합니다. 핸드셰이크 비용은 기동 시점에 한 번만 지불되고, 그다음에는 누군가 서비스를 재시작할 때까지 수백만 건의 요청에 걸쳐 얇게 퍼집니다.

Workers는 그렇게 동작하지 않습니다. 각 호출은 수명이 짧고 Cloudflare의 어느 위치에서나 실행될 수 있습니다. 풀을 붙들고 있는 장수 프로세스가 없으므로, 도움이 없다면 모든 요청이 연결 설정 비용을 전부 지불하며, 그것도 엣지에서 오리진 데이터베이스까지의 거리만큼 지불합니다.

첫 데이터 바이트가 나오기 전에 왕복이 세 번이라는 것은 튜닝 문제가 아닙니다. 런던의 Postgres와 대화하는 Worker를 시드니 사용자가 호출하면 그 지연 시간을 네 번 지불합니다. TCP, 그다음 TLS, 그다음 인증, 그리고 마지막에야 쿼리입니다. 정작 쿼리 자체는 2밀리초면 끝날 수도 있습니다.

두 번째, 더 조용한 실패도 있습니다. Postgres는 연결마다 백엔드 프로세스를 하나씩 할당하고 그 최대치는 유한하며 보통 수백 개 수준입니다. 동시 호출 수천 건까지 확장되는 Worker는 그 풀을 고갈시키고, 하필 여러분이 엣지를 구축한 이유였던 그 트래픽 급증 구간에서 연결 거부를 쌓기 시작합니다.

Hyperdrive는 이에 대해 무엇을 하는가

Hyperdrive는 Cloudflare가 여러분을 대신해 운영하는 커넥션 풀러로서 Worker와 데이터베이스 사이에 자리 잡습니다. 오리진을 향한 따뜻한 연결을 유지하므로, 호출은 새 연결을 처음부터 협상하는 대신 이미 있는 연결을 하나 빌립니다.

쿼리 결과도 캐시합니다. 반복되는 읽기 쿼리는 오리진을 전혀 건드리지 않고 응답할 수 있으며, 이는 트래픽의 상당 부분에서 지연 시간 문제를 캐시 적중률 문제로 바꿔 놓습니다. 쓰기와 비결정적인 작업은 그대로 통과합니다.

설정이라고 할 것은 연결 문자열 하나뿐입니다. Cloudflare에 데이터베이스를 등록하고 Hyperdrive 바인딩을 받은 다음, 기존 Postgres 드라이버를 데이터베이스가 아니라 그 바인딩으로 향하게 하면 됩니다. 드라이버도 SQL도 스키마도 바뀌지 않습니다. 이 점은 들리는 것보다 중요합니다. 변경이 되돌릴 수 있는 것이라는 뜻이고, 아무것도 다시 쓰지 않은 채로 직접 연결과 비교 측정할 수 있다는 뜻이기 때문입니다.

적합한지 판가름하는 숫자들

2026년 8월에 Cloudflare 문서와 대조해 확인한 값이며, 이 값들은 움직이므로 도입을 확정하기 전에 다시 확인하는 편이 좋습니다.

Hyperdrive는 두 요금제 어느 쪽에서도 추가 비용이 없고 이그레스 요금도 없습니다. 무엇을 쿼리로 세는지는 폭이 넓습니다. select, insert, update, delete, 스키마 변경이 모두 한 건으로 계산되고, 캐시에서 응답한 쿼리도 캐시하지 않은 쿼리와 똑같이 계산됩니다. 무료 일일 허용량은 UTC 자정에 초기화됩니다.

제한 문서 는 최초 연결 타임아웃 15초와 유휴 타임아웃 10분을 명시합니다. 쿼리당 60초 상한은 리포팅 워크로드를 옮기려는 팀이 걸려 넘어지는 지점입니다. 크론 잡에서 2분 걸리던 분석 쿼리는 여기서는 그냥 실패합니다.

실제로 동작하는 데이터베이스

Hyperdrive는 PostgreSQL 9.0부터 17.x까지, MySQL 5.7부터 8.x까지 를 자체 호스팅이든 매니지드든 지원합니다. MariaDB는 MySQL 호환 범위에 들어갑니다.

이름이 명시된 매니지드 제공업체로는 Postgres 호환과 MySQL 호환 양쪽 형태의 AWS Aurora, 그리고 Neon, Supabase, Timescale, Materialize, CockroachDB, PlanetScale이 있습니다. Azure와 Google Cloud의 매니지드 인스턴스도 동작합니다.

실질적인 제약은 엔진이 아니라 도달 가능성입니다. 데이터베이스가 Cloudflare 네트워크에서 주소로 접근 가능해야 합니다. 공개 엔드포인트 없이 프라이빗 VPC 안에 봉인된 Postgres 인스턴스는 Hyperdrive가 그것을 보기라도 하려면 터널이나 피어링 구성이 필요하고, 이는 설정 변경이 아니라 네트워크 프로젝트입니다.

Cloudflare Hyperdrive가 틀린 답인 경우

데이터가 엣지에 있어야 할 때. 접근 패턴이 키와 값 조회라면 Workers KV가 더 빠르고 더 단순합니다. 하나의 리전이 아니라 Worker 가까이에 사는 작은 관계형 데이터베이스를 원한다면 D1이 바로 그 용도로 설계된 제품입니다. Hyperdrive는 이미 Postgres나 MySQL을 쓰고 있고 앞으로도 계속 쓸 생각일 때를 위한 것입니다.

워크로드가 분석성일 때. 60초 상한과 쿼리 단위 과금은 트랜잭션 트래픽에 맞습니다. 긴 집계 작업은 데이터베이스와 직접 대화하는 잡 러너에 두는 편이 맞습니다.

측정하지 않았을 때. 저희가 가장 자주 보는 실패는 애초에 연결에 묶여 있지도 않던 애플리케이션에 팀이 Hyperdrive를 얹는 경우입니다. 한 번이면 될 것을 여섯 번 순차 쿼리로 처리해서 Worker가 느린 것이라면, 그 여섯 개의 연결을 풀링해 봤자 아주 조금 덜 느려질 뿐이고 진짜 문제는 그대로 남습니다.

그 측정은 다른 무엇보다 먼저 제대로 해 둘 가치가 있습니다. 저희가 정리한 Cloudflare Workers와 AWS Lambda 비교는 엣지 실행이 실제로 이기는 지점을 다루고, Cloudflare D1 글은 데이터베이스로 가는 길을 빠르게 만드는 것보다 데이터베이스 자체를 옮기는 편이 나은 경우를 다룹니다.

결정을 제대로 내리는 법

데이터베이스에서 멀리 떨어진 위치에서, 직접 연결로 요청 하나를 끝에서 끝까지 측정하고, 이어서 Hyperdrive를 거쳐 다시 측정하십시오. 차이가 작다면 지연 시간은 다른 곳에 살고 있으며 여러분은 의존성 하나를 아낀 셈입니다. 차이가 크다면 진짜 돈을 찾아낸 것입니다.

Mecanik은 소프트웨어 개발 팀을 통해 엣지 아키텍처를 설계하고 검토합니다. 여기에는 무엇이 실제로 느린지 누군가 먼저 측정한 다음에야 재설계에 손을 대는, 화려할 것 없는 과정도 포함됩니다. 서버리스 애플리케이션이 그것이 대체한 서버보다 느리다면, 가장 먼저 들여다볼 곳은 연결 경로입니다.

함께 읽기: Cloudflare Workers API 구축: 서버리스 가이드 2026 , Cloudflare Queues: 엣지의 백그라운드 작업 , LLM 지연 시간을 줄이는 방법: 캐싱과 에지 전략 그리고 2026년 웹 앱 개발 방법 .

자주 묻는 질문

Cloudflare Hyperdrive는 어떤 문제를 해결하나요? 모든 요청마다 데이터베이스 연결을 새로 여는 비용입니다. Worker는 수명이 짧고 연결 풀을 들고 있지 않으므로, Hyperdrive가 없으면 각 호출이 데이터가 한 바이트라도 움직이기 전에 엣지에서 데이터베이스까지의 거리를 두고 TCP 핸드셰이크와 TLS 협상과 인증 교환을 지불합니다. Hyperdrive는 오리진 가까이에 풀링된 따뜻한 연결을 유지해 Worker가 그중 하나를 빌려 쓰게 합니다.

Cloudflare Hyperdrive 요금은 얼마인가요? Workers 요금제 외에 추가로 드는 비용은 없습니다. 무료와 유료 요금제 모두에 포함되며 별도 요금도 이그레스 요금도 없습니다. 무료 요금제는 하루 100,000건의 데이터베이스 쿼리를 허용하고 UTC 자정에 초기화되며, 유료 요금제는 무제한입니다. select, insert, update, delete와 스키마 변경이 모두 쿼리로 계산되고, 캐시에서 응답한 쿼리도 캐시하지 않은 쿼리와 똑같이 계산됩니다.

Hyperdrive는 어떤 데이터베이스를 지원하나요? PostgreSQL 9.0부터 17.x까지, MySQL 5.7부터 8.x까지를 자체 호스팅이든 매니지드든 지원하며 MariaDB는 MySQL 호환 범위에 들어갑니다. 이름이 명시된 제공업체로는 AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB, PlanetScale이 있고 Azure와 Google Cloud의 매니지드 인스턴스도 포함됩니다. 데이터베이스는 Cloudflare 네트워크에서 도달 가능해야 합니다.

Hyperdrive의 주요 제한은 무엇인가요? 무료 요금제에서 계정당 구성 데이터베이스 열 개, 유료 요금제에서 25개, 구성당 오리진 연결이 무료에서 약 20개, 유료에서 100개, 쿼리 최대 실행 시간 60초, 캐시된 응답 크기 50 MB, 최초 연결 타임아웃 15초, 유휴 타임아웃 10분입니다. 쿼리당 60초 상한이 분석 워크로드를 막는 지점입니다.

Hyperdrive와 D1 중 무엇을 써야 하나요? 계속 쓸 Postgres나 MySQL 데이터베이스가 이미 있고 문제가 거기에 도달하는 지연 시간이라면 Hyperdrive입니다. 애초에 Cloudflare 네트워크 위에 사는 관계형 데이터베이스를 원한다면 D1입니다. 둘은 서로 다른 문제를 풉니다. 하나는 기존 데이터베이스로 가는 경로를 빠르게 하고, 다른 하나는 데이터를 옮겨서 거리 자체를 없앱니다.