"Azure" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

Cloud SQL for PostgreSQL이 2026년 7월 24일 릴리스 노트로 failover slot 지원을 GA로 발표했어요. logical replication을 쓰면서 DR switchover나 replica failover를 하는 환경에서 slot이 살아남게 하는 기능이에요.

CSP 릴리스 노트를 읽을 때마다 확인해야 하는 게 하나 있습니다. 이게 그 벤더가 만든 기능인지, 아니면 upstream 기능을 이제 노출한 것인지 살펴봐야 합니다. 이번 건은 후자입니다. failover slot은 PostgreSQL 17 코어 기능이고, AWS와 Azure도 이미 지원합니다. GCP가 늦게 합류한 쪽입니다.

그렇다고 릴리스 노트가 무의미하지는 않습니다. 관리형 서비스는 upstream 기능을 노출할 때 파라미터 이름을 자기 방식으로 바꾸고, 조건을 붙입니다. 실무에서 걸리는 건 그 차입니다. 3사 문서를 나란히 놓고 정리했습니다.

왜 slot이 failover에서 사라지면 곤란한가​

logical replication slot은 primary에만 존재했습니다. standby로 넘어가지 않았습니다. 그래서 failover가 일어나면 새 primary에는 그 slot이 없습니다.

slot이 없으면 구독자는 어디서부터 받아야 할지 모릅니다. 새로 slot을 만들면 그 시점부터 시작하므로, 옛 primary에서 마지막으로 읽은 지점과 새 slot 생성 시점 사이의 변경이 비게 됩니다. 안전하게 가려면 초기 스냅샷부터 다시 떠야 합니다. 수 TB 규모 CDC 파이프라인에서 이건 몇 시간에서 며칠짜리 작업입니다.

문제는 이 손실이 HA 구성을 갖췄다고 방지되지 않는다는 점입니다. HA는 데이터를 지키지만 slot은 데이터가 아닙니다. failover는 성공했는데 CDC만 끊기는 상황이 정확히 이 지점에서 나옵니다.

PostgreSQL 17이 한 일​

17에서 slot 동기화가 코어에 들어왔습니다. 동작은 이렇습니다. standby에 slotsync worker가 붙어 주기적으로 primary에 물어보고, failover 속성이 켜진 logical slot을 로컬에 만들거나 갱신합니다. 동기화가 필요 없어진 slot은 worker가 알아서 지웁니다.

켜려면 여러 조건이 맞아야 합니다.

-- 구독자 쪽: failover 옵션을 켜고 subscription 생성
CREATE SUBSCRIPTION mysub
  CONNECTION 'host=... dbname=...'
  PUBLICATION mypub
  WITH (failover = true);

-- publisher 쪽에서 확인
SELECT slot_name, slot_type, failover FROM pg_replication_slots;

failover 열이 t여야 동기화 대상이 됩니다. 여기가 첫 번째 함정입니다. 서버 파라미터를 다 맞춰 놓고도 subscription에 failover = true를 빼면 아무 slot도 동기화되지 않습니다. 3사 문서가 모두 이 문장을 따로 적어 둔 이유입니다. 이미 만들어 둔 subscription이 있으면 ALTER SUBSCRIPTION ... SET (failover = true)로 바꿔야 합니다.

서버 쪽 요구사항은 네 갈래입니다. standby에 sync_replication_slots를 켜고, hot_standby_feedback도 켭니다. standby와 primary 사이에 물리 replication slot이 있어야 하므로 standby의 primary_slot_name이 설정돼 있어야 합니다. 그리고 primary의 synchronized_standby_slots에 그 물리 slot 이름을 넣어, logical slot이 standby가 아직 받지 못한 지점보다 앞서 나가지 못하게 막습니다.

마지막 항목을 빼먹기 쉬운데, 이걸 안 걸면 동기화는 도는 것처럼 보이지만 failover 순간에 구독자가 새 primary에 없는 WAL을 요구하는 상태가 될 여지가 남습니다.

17 이전 버전은 코어에 이 기능이 없습니다. EDB의 pg_failover_slots extension으로 같은 일을 했고, 관리형 서비스 중에는 이 extension을 제공하는 곳이 있습니다.

3사 비교​

같은 upstream 기능인데 파라미터 이름이 셋 다 다릅니다. 문서를 옮겨 다니며 설정할 때 이 표가 필요합니다.

추상화 수준이 갈리는 지점​

표에서 가장 눈여겨볼 행은 primary 쪽 대기 지정입니다.

AWS는 synchronized_standby_slots에 물리 replication slot 이름을 넣으라고 합니다. upstream 파라미터 그대로입니다. 그 slot 이름을 알아야 하고, 인스턴스를 재구성하면 값을 손봐야 합니다.

GCP는 cloudsql.synchronized_standby_replicas에 replica 인스턴스 이름을 넣으라고 합니다. 물리 slot 이름이 아니라 GCP 리소스 이름입니다. 내부에서 인스턴스 이름을 slot 이름으로 옮겨 준다는 뜻이고, 사용자가 PostgreSQL 내부 식별자를 몰라도 됩니다. 대신 그 매핑이 어떻게 되는지는 밖에서 안 보입니다.

이 차이가 두 서비스의 성격을 보여줍니다. AWS는 upstream 파라미터를 그대로 열어 주고 접두사만 붙이는 쪽이고, GCP는 자기 리소스 모델로 감싸는 쪽입니다. 어느 쪽이 낫다기보다, 셀프 호스팅 경험을 그대로 옮기려면 AWS가 편하고 PostgreSQL 내부를 몰라도 쓰게 하려면 GCP가 편합니다.

failover 이후 구독자가 해야 하는 일​

AWS 문서는 standby가 승격된 뒤 구독자가 subscription을 새 인스턴스로 바꿔야 한다고 적습니다. slot은 살아 있으니 재동기화는 필요 없지만 접속 대상은 사람이 바꿔 줍니다.

GCP는 구독자가 private services access DNS 쓰기 엔드포인트로 접속해 있으면 switchover나 failover 뒤 자동으로 새 primary에 재연결된다고 안내합니다. 엔드포인트가 이름으로 고정되어 있고 그 이름이 새 primary를 가리키게 바뀌기 때문입니다. 같은 주에 프리뷰로 나온 AlloyDB write endpoint와 같은 발상입니다.

다만 GCP 문서에도 단서가 붙습니다. 승격된 replica에 남은 옛 primary의 orphaned slot은 수동으로 지워야 하고, 구독자가 그 옛 slot에 계속 붙으려 하는 경우가 있습니다. 자동 재연결이 모든 잔여물을 정리해 주지는 않습니다.

Aurora는 어떤가​

여기는 정확히 적어야 합니다. AWS가 문서로 명시한 페이지는 "Managing logical slot synchronization for RDS for PostgreSQL"이고, 대상을 RDS for PostgreSQL 17로 적고 있습니다. Aurora PostgreSQL에 대한 동일한 안내 페이지는 확인하지 못했습니다.

Aurora는 read replica가 스토리지를 공유하는 구조라 물리 replication slot의 의미가 RDS와 다릅니다. 위 파라미터 조합이 그대로 통한다고 단정할 근거를 찾지 못했으니, Aurora를 쓴다면 엔진 버전과 파라미터 그룹에서 sync_replication_slots가 실제로 노출되는지 확인하고 테스트 클러스터에서 failover를 걸어 보는 편이 안전합니다. 검색에 잡히는 "Aurora 17도 된다"는 서술은 대부분 커뮤니티 글이라 1차 출처로 삼기 어렵습니다.

셀프 호스팅에서 확인하는 법​

관리형 대신 직접 운영하는 경우 설정과 검증은 이렇습니다.

# primary
wal_level = logical
synchronized_standby_slots = 'standby_phys_slot'

# standby
primary_slot_name = 'standby_phys_slot'
hot_standby_feedback = on
sync_replication_slots = on

동기화가 실제로 되고 있는지는 standby에서 확인합니다.

-- standby에 slot이 만들어졌는지, 어디까지 따라왔는지
SELECT slot_name, failover, synced, restart_lsn, confirmed_flush_lsn
FROM   pg_replication_slots
WHERE  slot_type = 'logical';

synced 열이 t면 slotsync worker가 만든 복제본입니다. 수동으로 한 번 당겨 보려면 standby에서 SELECT pg_sync_replication_slots();를 실행합니다.

primary 쪽에서는 logical slot이 얼마나 뒤처져 있는지 봅니다.

SELECT slot_name, slot_type, failover,
       restart_lsn,
       pg_current_wal_lsn() - restart_lsn AS lag_bytes
FROM   pg_replication_slots
ORDER  BY slot_type, slot_name;

synchronized_standby_slots를 걸면 logical slot의 진행이 물리 slot에 묶이므로, standby가 멈추면 primary의 WAL이 쌓인다는 점을 같이 알고 있어야 합니다. 이 파라미터는 안전을 사는 대신 standby 장애를 primary 디스크 문제로 번지게 만드는 통로가 됩니다. restart_lsn 지연을 알림에 걸어 두는 게 좋습니다.

정리​

Cloud SQL 릴리스 노트 한 줄을 따라가면 결국 PostgreSQL 17 코어 기능에 도착합니다. 3사가 모두 지원하고, 최소 버전도 셋 다 17입니다. 차이는 기능 유무가 아니라 파라미터 이름과 추상화 수준, 그리고 failover 이후 구독자 재연결을 누가 처리하느냐에 있습니다.

GCP만 Enterprise Plus edition과 Advanced DR을 요구한다는 점은 비교할 때 짚어 둘 만합니다. 기능이 있다는 것과 지금 쓰는 요금제에서 쓸 수 있다는 것은 다른 이야기입니다.

어느 클라우드를 쓰든 첫 번째 함정은 같습니다. subscription에 failover = true가 걸려 있지 않으면 서버 파라미터를 전부 맞춰도 아무 slot이 동기화되지 않습니다. 설정을 끝냈다고 생각한 시점에 pg_replication_slots의 failover 열부터 확인하는 게 순서입니다.

참고​

• Cloud SQL for PostgreSQL 릴리스 노트 2026-07-24 failover slot GA
• Advanced disaster recovery with logical failover slot (Google Cloud)
• Managing logical slot synchronization for RDS for PostgreSQL (AWS)
• Logical replication and logical decoding (Azure), Failover support for logical replication slots 절
• PostgreSQL 문서: Logical Replication Failover
• pg_failover_slots (EDB) PostgreSQL 17 이전 대안
• Failover Slots in PostgreSQL 17이 기능을 커밋한 Amit Kapila(아미트 카필라)의 설명

이 블로그의 관련 글로는 PostgreSQL 19의 logical replication과 sequence와 PostgreSQL 19의 wal_level 동적 floor가 있어요.

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 호환을 새로 짓는다"는 한 문장으로 묶이지만, 세 제품이 노리는 지점은 조금씩 다릅니다. 그대로 같은 칸에 놓고 비교하면 오해가 생깁니다.

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파전이 한층 또렷해졌어요.