Azure HorizonDB: 마이크로소프트가 PostgreSQL을 다시 만든 이유

이미 PostgreSQL 서비스가 있는데

Azure에는 이미 Azure Database for PostgreSQL이 있습니다. 그런데 Ignite 2025에서 마이크로소프트는 PostgreSQL 호환 서비스를 하나 더 내놓았습니다. Azure HorizonDB입니다.

왜 하나 더 만들었을까. 발표 글을 읽으며 가장 궁금했던 질문입니다. 답은 구조에 있었습니다.

컴퓨트와 스토리지를 떼어 냈다

HorizonDB는 클라우드 네이티브 구조로 다시 설계됐습니다. 핵심은 컴퓨트와 스토리지의 분리입니다.

• 컴퓨트: 기본 노드와 복제본 노드를 합쳐 최대 3,072 vCore까지 확장
• 스토리지: 자동으로 늘어나는 공유 스토리지, 데이터베이스 최대 128TB
• 복제: 기본으로 가용 영역 사이에 복제

기존 관리형 PostgreSQL은 대부분 서버 한 대에 디스크가 붙은 구조입니다. 읽기 복제본을 늘리면 데이터도 복제본마다 복사됩니다. HorizonDB는 여러 컴퓨트가 하나의 공유 스토리지를 봅니다. AWS의 Aurora, 구글의 AlloyDB가 택한 방향과 같습니다.

결국 Azure도 이 구조의 PostgreSQL이 필요했던 겁니다. 기존 서비스를 고치기보다 새로 만드는 쪽을 택한 것으로 보입니다.

성능 주장

발표 글의 성능 수치는 두 가지입니다.

• 트랜잭션 워크로드에서 오픈소스 PostgreSQL 대비 처리량 최대 3배
• 공유 스토리지 계층 덕분에 다중 영역 커밋 지연 1ms 미만

두 번째 수치가 더 의미 있어 보입니다. 가용 영역 사이에 동기 복제를 하면서도 커밋이 1ms 안에 끝난다면, 고가용성을 위해 성능을 포기하던 절충이 줄어듭니다. 물론 둘 다 마이크로소프트가 잰 수치이고, 측정 조건은 글에 자세히 나오지 않습니다.

벡터 검색에서 필터가 중요한 이유

AI 기능 중에서는 DiskANN 벡터 인덱스의 고급 필터링이 눈에 띕니다.

벡터 검색에는 고질적인 문제가 있습니다. "비슷한 상품 10개를 찾되, 재고가 있고 서울 매장에 있는 것만"처럼 조건이 붙으면 성능이 떨어지거나 결과가 모자랍니다. 비슷한 것 100개를 먼저 찾고 조건으로 거르면, 조건에 맞는 게 3개만 남을 수 있습니다.

HorizonDB는 질의 조건을 벡터 유사도 검색 안으로 밀어 넣는다고 설명합니다. 거르면서 찾는 방식입니다. 발표 글은 이 방식이 pgvector의 HNSW보다 성능과 확장성에서 낫고 정확도는 유지한다고 주장합니다.

Microsoft Foundry의 생성·임베딩·재순위 모델을 설정 없이 붙여 쓸 수 있는 모델 관리 기능도 들어 있습니다.

Oracle에서 넘어오는 길

마이그레이션 쪽 발표도 있습니다. VS Code의 PostgreSQL 확장에 GitHub Copilot 기반 Oracle 이전 기능이 프리뷰로 들어갔습니다. 데이터베이스 코드 변환을 처음부터 끝까지 자동화한다는 설명입니다.

PL/SQL 프로시저를 PL/pgSQL로 옮기는 일은 원래 사람이 한 줄씩 하던 지루한 작업입니다. Copilot이 초안을 만들고 사람이 검토하는 방식이라면 시간을 꽤 줄일 수 있겠습니다. 다만 변환 결과가 같은 결과를 내는지 확인하는 테스트는 여전히 사람 몫입니다.

함께 나온 데이터베이스 소식

Azure 블로그의 목록에서 나머지를 정리하면 이렇습니다.

그 뒤의 소식

발표 당시 HorizonDB는 신청을 받는 프리뷰였고, 미국 중부, 미국 서부 3, 영국 남부, 오스트레일리아 동부 네 리전에서 시작했습니다. 2026년 6월 Build에서는 공개 프리뷰로 넘어갔습니다.

새 PostgreSQL 워크로드를 Azure에 올린다면, 이제 선택지가 둘입니다. 작고 단순하면 기존 Flexible Server, 크게 확장하거나 다중 영역 고가용성이 중요하면 HorizonDB입니다. 아직 정식 출시 전이니, 운영 워크로드라면 출시 일정과 SLA를 먼저 확인하세요.

함께 읽을 개념 정리

• 벡터 검색에 조건을 붙이면 결과가 모자라는 이유: 근사 검색과 필터링이 부딪히는 지점