Azure HorizonDB 공개 프리뷰
Microsoft가 Build 2026에서 Azure HorizonDB를 공개 프리뷰로 내놓았어요. compute와 storage를 분리한 scale-out 구조 위에 벡터 검색과 in-database 모델 호출을 얹은 PostgreSQL 호환 관리형 데이터베이스예요.
작년 12월 Ignite에서 early preview로 처음 모습을 비친 뒤, 2026-06-03 Build 발표로 공개 프리뷰에 들어갔습니다. 같은 시기 AWS는 Aurora DSQL을 정식 출시했고, Google은 AlloyDB를 계속 키우는 중입니다. 클라우드 3사가 약속이라도 한 듯 "PostgreSQL 호환"을 새로 짓고 있습니다.
발표를 사실 단위로 끊어 보면
발표를 사실 단위로 끊어 정리합니다. 1차 출처는 Microsoft 공식 블로그와 Azure 블로그의 Build 2026 데이터베이스 발표입니다.
- HorizonDB는 PostgreSQL 호환 관리형 데이터베이스입니다. 기존 Azure Database for PostgreSQL과 별개의 새 서비스로 출발했습니다.
- compute와 storage를 분리하고, 공유 storage 위에서 scale-out하는 구조입니다. Microsoft는 "compute와 storage를 완전히 분리했다"고 적었습니다.
- scale-out compute는 primary와 replica 노드를 합쳐 최대 3,072 vCore까지, auto-scaling 공유 storage는 최대 128TB까지 지원한다고 밝혔습니다.
- 다중 zone에 걸쳐 sub-millisecond commit latency를 낸다고 주장합니다.
- 트랜잭션 워크로드 기준 오픈소스 PostgreSQL 대비 최대 3배 throughput을 주장합니다. Microsoft가 든 예시는 self-managed 4,200 TPS 대비 HorizonDB 11,000+ TPS입니다.
- AI 쪽으로는 DiskANN 기반 벡터 검색, pgvector, pg_textsearch를 묶은 hybrid search, 그리고 SQL에서 모델을 직접 호출하는 azure_ai extension을 얹었습니다.
공개 프리뷰는 일부 region에서 먼저 열렸습니다. Australia East, Central US, Sweden Central, West US 2, West US 3에서 시작하고, East US, Canada Central, Japan East, Korea Central 등은 곧 추가된다고 밝혔습니다. AI 모델 관리 기능은 별도로 limited preview 단계입니다.
storage 계층을 새로 짠 아키텍처
HorizonDB가 내세우는 핵심은 storage 계층 재설계입니다. Microsoft는 이를 "database-as-logs" 설계라고 부르는데, 트랜잭션을 공유 WAL storage에 직접 commit하는 방식입니다. compute 노드는 상태를 로컬에 묶어두지 않고, 영속성은 분리된 공유 storage가 책임집니다.
이렇게 분리하면 운영 관점에서 두 가지가 달라집니다. 첫째, write latency를 낮추고 commit을 다중 zone에 걸쳐 처리하면서도 sub-millisecond를 노립니다. 둘째, failover가 예측 가능해집니다. compute 노드가 죽어도 데이터는 공유 storage에 남아 있으므로, 새 노드가 같은 storage를 붙잡으면 됩니다. 데이터를 통째로 옮기는 과정이 빠지기 때문입니다.
PostgreSQL 호환의 의미도 짚어야 합니다. HorizonDB는 PostgreSQL 엔진 위에서 storage 계층을 갈아끼운 형태에 가깝습니다. planner, executor, SQL 문법, extension 생태계 같은 PostgreSQL 상단은 그대로 두고, heap과 WAL이 디스크에 닿는 아래쪽을 클라우드 native storage로 바꾼 구조입니다. 그래서 기존 드라이버, ORM, extension을 그대로 쓰면서도, 단일 인스턴스 PostgreSQL의 storage 한계를 우회하려 합니다.
AI 기능 중 눈에 띄는 건 azure_ai extension입니다. 모델 추론을 PostgreSQL 엔진 안으로 끌어들여 SQL에서 함수로 호출하게 합니다. 임베딩 생성이나 추론을 위해 애플리케이션이 외부 모델 서비스로 따로 나갔다 오는 orchestration 계층을 줄이려는 의도입니다. 벡터 검색은 Microsoft의 DiskANN을 써서 메모리와 디스크를 함께 활용하고, 필터를 건 그래프 탐색도 빠르게 처리한다고 주장합니다.
Aurora DSQL/AlloyDB와의 구도
"PostgreSQL 호환을 새로 짓는다"는 한 문장으로 묶이지만, 세 제품이 노리는 지점은 조금씩 다릅니다. 그대로 같은 칸에 놓고 비교하면 오해가 생깁니다.
| 항목 | Azure HorizonDB | AWS Aurora DSQL | Google AlloyDB |
|---|---|---|---|
| 상태 | 공개 프리뷰(2026-06) | 정식 출시(2025-06 GA) | 정식 출시 |
| 호환 기준 | PostgreSQL 호환 | PostgreSQL 16 호환 | PostgreSQL 완전 호환(18 GA) |
| 구조 | compute/storage 분리 scale-out | 컴포넌트 분리 active-active 분산 SQL | compute/storage 분리(log 기반) |
| 강점 | sub-ms commit, AI 내장 | 무한 확장, 다중 region 쓰기 | 분석 columnar engine, HTAP |
| 호환성 제약 | 프리뷰, 검증 진행 중 | foreign key/일부 타입 미지원, 재시도 로직 필요 | 표준에 가까움 |
| 주 경쟁 상대 | 단일 PG 한계를 넘는 관리형 PG | 분산 SQL(Spanner/CockroachDB) | Aurora/관리형 PG |
Aurora DSQL은 결이 가장 다릅니다. query processor, adjudicator, journal 같은 컴포넌트를 쪼개 독립 확장하는 active-active 분산 SQL이고, sharding 없이 읽기/쓰기를 따로 확장한다고 내세웁니다. 대신 10,000 row 트랜잭션 제한, foreign key/일부 타입 미지원, optimistic concurrency에 따른 애플리케이션 재시도 로직 같은 제약이 따라붙습니다. 분류상 Spanner/CockroachDB 쪽 분산 SQL과 경쟁합니다.
AlloyDB는 Aurora와 같은 칸에 있는, compute/storage를 분리한 관리형 PostgreSQL입니다. 가장 큰 차별점은 columnar engine입니다. 분석 쿼리에서 오픈소스 PostgreSQL 대비 최대 100배 빠르다고 주장하며 HTAP를 노립니다. PostgreSQL 18도 이미 GA에 올렸습니다.
HorizonDB는 이 둘 사이 어딘가에 있습니다. Aurora DSQL처럼 호환성을 깨면서까지 분산 SQL로 가지 않고, AlloyDB처럼 compute/storage 분리에 머무르되, 차별점을 sub-millisecond commit과 AI 내장 쪽으로 잡았습니다. 정리하면 셋 다 "단일 인스턴스 PostgreSQL의 storage/확장 한계"라는 같은 문제를 풀되, AWS는 분산 일관성, Google은 분석, Microsoft는 AI 워크로드라는 서로 다른 입구로 들어간 셈입니다.
기존 Azure Database for PostgreSQL과 무엇이 다른가
이미 Azure Database for PostgreSQL flexible server를 쓰고 있다면, 당장 옮길 이유는 없습니다. HorizonDB는 별개의 새 서비스이고 아직 프리뷰입니다. 프로덕션 SLA, 모든 region, 익숙한 운영 도구가 다 갖춰지기 전까지는 검증 대상으로 보는 게 맞습니다.
차이를 운영 관점에서 추리면 이렇습니다.
- storage 확장: flexible server는 단일 인스턴스 모델이라 storage/IOPS에 인스턴스 단위 상한이 있습니다. HorizonDB는 공유 storage를 최대 128TB까지 auto-scaling으로 키운다고 주장합니다. 한 데이터베이스가 수십 TB로 커지는 워크로드라면 이 차이가 큽니다.
- 읽기 확장과 failover: scale-out compute와 공유 storage 분리는 replica 추가와 failover를 가볍게 만듭니다. 데이터를 통째로 옮기지 않고 같은 storage를 붙잡는 구조이기 때문입니다.
- AI 워크로드: 벡터 검색과 in-database 모델 호출이 엔진에 들어 있어, 임베딩/검색을 별도 서비스로 빼지 않고 SQL 안에서 처리하려는 설계입니다. RAG나 agent용 데이터 계층을 PostgreSQL 한 곳에 모으려는 경우 매력이 있습니다.
반대로 신중하게 볼 점도 있습니다. 3배 throughput, sub-millisecond commit 같은 숫자는 모두 Microsoft가 자기 벤치마크로 든 주장입니다. 워크로드, region, 구성에 따라 결과는 달라지므로, 옮기기 전에 자기 데이터로 직접 측정하는 게 맞습니다. extension 호환 범위, 기존 flexible server에서의 마이그레이션 경로, 백업, PITR, 모니터링 도구가 어디까지 따라오는지도 프리뷰 기간에 확인할 항목입니다.
큰 그림에서 보면, 클라우드 벤더가 PostgreSQL 호환을 새로 짓는 흐름은 PostgreSQL이 사실상 관리형 데이터베이스의 공통 인터페이스가 됐다는 신호입니다. 엔진은 같은 PostgreSQL을 쓰되 storage와 확장 계층을 각자 새로 짜고, 그 위에 AI, 분석, 분산이라는 차별점을 얹습니다. DBA 입장에서는 PostgreSQL 한 가지 언어로 여러 벤더의 관리형 제품을 평가할 수 있다는 뜻이고, 동시에 "호환"이라는 단어 뒤에 숨은 제약을 제품마다 따져야 한다는 뜻이기도 합니다.
HorizonDB는 아직 프리뷰예요. 하지만 방향은 분명해요. Microsoft는 PostgreSQL 위에 storage를 갈아끼우고 AI를 엔진 안으로 끌어들이는 길을 택했고, 이 선택이 Aurora DSQL/AlloyDB와 나란히 놓이면서 "PostgreSQL 호환을 새로 짓는" 3파전이 한층 또렷해졌어요.