Azure HorizonDB 공개 프리뷰 — 클라우드 3사가 다시 짓는 PostgreSQL

한 줄 요약

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 단계다.

HorizonDB 아키텍처 — 무엇이 “재설계"됐나

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을 써서 메모리와 디스크를 함께 활용하고, 필터를 건 그래프 탐색도 빠르게 처리한다고 주장한다.

flowchart TD
    APP["애플리케이션 / agent"]
    SQL["PostgreSQL 엔진
(planner·executor·SQL)"]
    AI["azure_ai extension
(SQL에서 모델 호출)"]
    VEC["DiskANN 벡터 검색
pgvector·hybrid"]
    COMPUTE["scale-out compute
(최대 3072 vCore)"]
    STORE["공유 WAL storage
(최대 128TB)"]

    APP --> SQL
    SQL --> AI
    SQL --> VEC
    SQL --> COMPUTE
    COMPUTE --> STORE

Aurora DSQL · AlloyDB와의 구도

“PostgreSQL 호환을 새로 짓는다"는 한 문장으로 묶이지만, 세 제품이 노리는 지점은 조금씩 다르다. 그대로 같은 칸에 놓고 비교하면 오해가 생긴다.

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 워크로드라는 서로 다른 입구로 들어간 셈이다.

DBA 관점 — 기존 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 한 가지 언어로 여러 벤더의 관리형 제품을 평가할 수 있다는 뜻이고, 동시에 “호환"이라는 단어 뒤에 숨은 제약을 제품마다 따져야 한다는 뜻이기도 하다.

flowchart TD
    PG["PostgreSQL
(공통 호환 기준)"]
    MS["Azure HorizonDB
AI 워크로드"]
    AWS["AWS Aurora DSQL
분산 SQL"]
    GCP["Google AlloyDB
분석·HTAP"]

    PG --> MS
    PG --> AWS
    PG --> GCP

HorizonDB는 아직 프리뷰다. 하지만 방향은 분명하다. Microsoft는 PostgreSQL 위에 storage를 갈아끼우고 AI를 엔진 안으로 끌어들이는 길을 택했고, 이 선택이 Aurora DSQL·AlloyDB와 나란히 놓이면서 “PostgreSQL 호환을 새로 짓는” 3파전이 한층 또렷해졌다.