Materialize v26.33: PostgreSQL 메타데이터 DB를 READ COMMITTED로 바꾸고 혼잡한 클러스터 경합을 줄이는 방식

왜 지금 봐야 하나

Materialize는 v26.1.0부터 매주 릴리스하는 제품이라, 겉으로 보면 v26.33도 평범한 주간 업데이트처럼 보인다. 그런데 2026년 7월 16일/17일 공개된 v26.33은 query-heavy cluster에서 어디가 먼저 막히는지 를 바꾸는 릴리스에 가깝다.

핵심은 세 가지다.

• Self-Managed + PostgreSQL metadata DB 환경에서는 내부 consensus query를 SERIALIZABLE 대신 READ COMMITTED 로 돌릴 수 있게 됐다. 공식 업그레이드 노트는 이 query들이 READ COMMITTED 에서도 linearizable 하도록 설계됐다고 밝힌다.
• session duration 동안 catalog snapshot을 캐시 하도록 바뀌면서, 릴리스 노트 기준 query-heavy cluster에서 최대 13% QPS 개선이 관찰됐다.
• 느린 timestamp oracle이 다른 세션의 EXPLAIN TIMESTAMP 와 SUBSCRIBE 를 같이 멈추게 하던 경합 을 줄였고, MCP developer endpoint는 이제 EXPLAIN ANALYZE 를 특정 replica에 직접 붙여서 실행할 수 있다.

중요한 점은 이것이 단순한 속도 자랑이 아니라는 데 있다. 운영자에게는 “메타데이터 쓰기 재시도”, “세션 단위 catalog lookup”, “replica별 진단”, “timestamp oracle 병목 분리”처럼 제어면(control plane)에서 체감되는 문제를 어떻게 줄일 것인가 의 문제로 읽히기 때문이다.

반대로 말하면, 이 릴리스를 그냥 "성능이 조금 좋아졌다" 정도로만 보면 놓치는 것이 많다. 특히 Self-Managed 환경에서 PostgreSQL metadata DB를 쓰는 팀이라면, 이번 변화는 격리 수준을 낮췄는데도 correctness를 유지한다고 제품이 공식 선언한 첫 운영 경계 라는 점에서 의미가 크다.

이 장은 Materialize 공식 릴리스 노트(v26.33.0), Self-Managed upgrade notes, general upgrading guide를 기준으로 정리했다. Cloud 하드웨어 교체로 인한 hydration time 개선(10%~66%)은 공식 수치지만, underlying hardware 구성은 공개되지 않았으므로 이 글에서는 운영 판단 포인트만 다룬다.

Materialize v26.33 핵심 변화 요약

Materialize v26.33 제어면 경합 완화 아키텍처

1. 이번 릴리스의 중심은 메타데이터 DB 격리 수준 변경이다

릴리스 노트만 보면 v26.33의 headline은 짧다. PostgreSQL metadata database를 쓰는 Self-Managed 배포에서 persist_pg_consensus_read_committed 파라미터를 켜면, 내부 metadata query를 SERIALIZABLE 대신 READ COMMITTED 로 돌릴 수 있다는 내용이다.

하지만 업그레이드 노트가 밝히는 설명은 훨씬 중요하다.

• 이 변경은 Materialize의 client transaction isolation 을 바꾸는 것이 아니다.
• 대상은 PostgreSQL metadata database에 대해 Materialize가 내부적으로 수행하는 consensus query 다.
• 공식 문구대로, 이 query들은 READ COMMITTED 에서도 linearizable 하도록 설계 됐다.
• 목적은 correctness를 버리는 것이 아니라, SERIALIZABLE 이 경합 시 만들어 내는 serialization-failure retry를 줄여 metadata write throughput을 올리는 것 이다.

여기서 운영자가 읽어야 하는 포인트는 명확하다. 보통 운영 도중 "격리 수준을 낮춰 성능을 올린다"는 말은 경계심부터 들어야 한다. 그런데 Materialize는 이번에는 그 변경을 제품 설계 가정 안으로 공식 편입 했다. 즉, 이건 임시 튜닝 팁이 아니라 업그레이드 노트에 적힌 지원 경로 다.

{
  "persist_pg_consensus_read_committed": true
}

ALTER SYSTEM SET persist_pg_consensus_read_committed = true;

다만 안전장치도 강하게 걸려 있다.

1. 기본값은 off 다.
2. PostgreSQL metadata DB에만 적용 된다.
3. v26.33 이상으로 전체 환경 업그레이드가 끝난 뒤에만 켜야 한다.
4. PostgreSQL이 아닌 metadata DB에서 이 파라미터를 켜면 Materialize는 consensus query 실행을 거부한다.

즉, 이 기능의 메시지는 "이제 누구나 READ COMMITTED로 바꾸라"가 아니다. 정확히는 PostgreSQL-backed self-managed control plane에서만, 제품이 보장하는 방식으로 retry overhead를 줄일 수 있다 는 선언이다.

왜 하필 metadata write throughput인가

Materialize의 data plane은 스트리밍 계산과 replica 실행 경로가 중심이지만, 운영 중 실제로 사람을 느리게 만드는 구간은 종종 control plane이다.

• role / object / cluster / connection 변경
• schema 조정
• deployment rollout 중 catalog 관련 작업
• 운영 자동화가 연속적으로 metadata를 만지는 시간대

이런 작업이 SERIALIZABLE retry에 자주 걸리면, 사용자는 체감상 "쿼리는 돌아가는데 운영 작업이 이상하게 느리다"고 느끼게 된다. v26.33은 바로 이 병목을 겨냥한다.

2. query-heavy cluster에서는 catalog snapshot cache가 더 직접적인 체감 포인트다

릴리스 노트가 함께 적어 둔 두 번째 변화는, catalog snapshot을 세션 동안 캐시 한다는 점이다. 설명은 짧지만 운영상 의미는 크다.

Materialize 같은 시스템에서 catalog lookup은 완전히 사소한 경로가 아니다. query planning, object resolution, privilege 확인, session context 해석 같은 곳에서 catalog를 자주 본다. query-heavy cluster에서는 이 lookup이 작더라도 반복 비용이 된다.

v26.33은 이 반복 비용을 세션 경계 안에서 재사용 가능한 snapshot 으로 줄였다. 공식 릴리스 노트는 이 변경으로 테스트에서 최대 13% QPS 개선 을 봤다고 적는다. 중요한 건 숫자 자체보다 개선 방식이다.

• 글로벌 shared bottleneck을 더 빠르게 만든 것이 아니라,
• 같은 세션이 같은 catalog state를 반복해서 다시 읽는 비용을 줄인 것 이다.

이 방식은 운영자에게 두 가지 해석을 준다.

1. 짧은 연결을 매우 많이 만드는 환경 과 세션을 길게 재사용하는 환경 의 체감 차이가 다를 수 있다.
2. query latency regression을 볼 때 data plane만 보지 말고, catalog access pattern과 session reuse pattern 도 함께 봐야 한다.

여기서부터는 공식 문서의 직접 설명이라기보다 운영 해석이다. 세션 스코프 캐시는 대개 쿼리 엔진 전체를 빠르게 만드는 만능 장치가 아니다. 대신 카탈로그를 자주 만지는 계획/해석 경로를 세션 안으로 접어 넣어, query-heavy cluster에서 공용 경합을 조금 덜 공유하게 만드는 조정 에 가깝다.

3. 느린 timestamp oracle을 클러스터 전체 문제로 번지게 두지 않는다

v26.33 릴리스 노트의 세 번째 포인트는 한 줄이지만, incident 관점에서 보면 의외로 중요하다.

slow timestamp oracle no longer stalls unrelated sessions that are running EXPLAIN TIMESTAMP or SUBSCRIBE

이 문장이 의미하는 바는, 특정 세션이나 경로에서 timestamp oracle이 늦어져도 그 영향이 관계없는 다른 세션의 진단 경로와 구독 경로로 같이 번지지 않도록 분리했다는 것이다.

운영자가 이런 종류의 변경을 좋아하는 이유는 단순하다. 병목은 완전히 없애지 못해도, 폭발 반경(blast radius) 을 줄이면 장애 양상이 달라지기 때문이다.

기존에는 다음과 같은 상황이 더 난감했다.

• 어떤 이유로 timestamp oracle이 느려진다.
• 운영자는 원인을 보려고 EXPLAIN TIMESTAMP 를 찍는다.
• 실시간 소비 경로인 SUBSCRIBE 쪽도 같이 흔들린다.
• 문제를 진단하려는 도구와 영향받는 워크로드가 같은 병목에 묶인다.

v26.33의 의도는 이 고리를 끊는 데 있다. 이것 역시 "평균 성능"보다 운영 중 진단 가능성 을 높이는 변화다.

4. MCP replica 지정 EXPLAIN ANALYZE 는 multi-replica cluster 운영자에게 바로 쓸모가 있다

릴리스 노트는 MCP developer endpoint의 query tool이 optional replica 파라미터를 지원해, EXPLAIN ANALYZE 를 특정 replica에 직접 보낼 수 있다고 적는다.

이 변화가 좋은 이유는 multi-replica cluster에서 흔히 생기는 다음 질문을 더 빨리 분리해 주기 때문이다.

• 느린 것이 cluster 전체 문제인가?
• 특정 replica만 느린가?
• 같은 logical query인데 replica별 runtime profile이 다른가?

기존에는 replica별 차이를 보려면 세션 라우팅이나 수동 연결 경로를 더 복잡하게 잡아야 했다. 이제는 MCP developer endpoint를 이미 운영 도구로 쓰는 팀이라면, 진단 단계에서 replica를 먼저 고정하고 비교 할 수 있다.

이 기능은 성능 개선 자체라기보다 성능 개선을 검증하는 도구면의 개선 에 가깝다. 그래서 v26.33 전체를 보면, 제어면 경합 완화와 진단 경로 분리가 한 방향으로 정렬돼 있다고 볼 수 있다.

5. Cloud hydration 개선은 반갑지만, 운영자가 직접 조정할 수 있는 변화는 아니다

릴리스 노트는 Materialize Cloud 전 환경의 cluster hardware를 교체해 hydration time이 10%~66% 감소 했다고 적는다. 이 수치는 분명 반갑다. 특히 compute-intensive operation이 많은 팀이라면 refresh / restart / failover 뒤 복구 체감이 달라질 수 있다.

다만 이 변화는 Cloud only 이고, 하드웨어 세부가 공개된 것은 아니다. 따라서 운영 판단은 다음 정도로 제한하는 편이 좋다.

• Cloud 사용자는 별도 migration 없이 자동 적용된 개선으로 본다.
• 하지만 내부 원인은 공개되지 않았으므로, 자기 워크로드의 hydration 관찰값 을 다시 재는 것이 우선이다.
• Self-Managed 사용자는 이 항목을 자기 환경에 일반화하면 안 된다.

즉, 이 항목은 "조정 포인트"가 아니라 "관찰 포인트"다.

6. 업그레이드와 롤아웃은 이렇게 보는 편이 안전하다

Materialize의 general upgrading guide는 두 가지 원칙을 분명히 적는다.

1. 항상 target version의 version-specific upgrade notes를 먼저 확인할 것
2. 항상 Materialize Operator를 먼저 업그레이드한 뒤 인스턴스를 업그레이드할 것

또 major version은 한 번에 하나씩만 건널 수 있다.

여기에 v26.33의 version notes를 합치면, 실제 롤아웃 순서는 대략 이렇게 정리된다.

Self-Managed + PostgreSQL metadata DB

1. 현재 배포가 PostgreSQL metadata DB를 쓰는지 확인한다.
2. target path가 v26.33 이상으로 무리 없는지 general upgrading guide와 version notes를 본다.
3. Materialize Operator를 먼저 올린다.
4. 인스턴스를 v26.33+ 로 올린다.
5. 전체 환경 업그레이드가 끝난 뒤 persist_pg_consensus_read_committed 를 켠다.
6. metadata-heavy 운영 작업 시간대에 before/after 체감을 비교한다.

Self-Managed + non-PostgreSQL metadata DB

• 이번 기능은 적용 대상이 아니다.
• 억지로 켜는 경로는 지원되지 않으며, Materialize가 query 실행을 거부한다.

Materialize Cloud

• READ COMMITTED 파라미터는 이 글의 핵심이 아니다.
• 대신 hydration 개선과 query-heavy cluster의 catalog/timestamp 경합 완화가 관찰 포인트다.

운영자가 바로 써볼 체크리스트

채택해 볼 만한 경우

• Self-Managed 환경에서 PostgreSQL metadata DB를 사용한다.
• DDL / catalog 변경 / role 관리 / cluster 조정 같은 control-plane 작업이 유난히 느리다.
• serialization retry 때문에 metadata write throughput이 흔들리는 체감이 있다.
• query-heavy cluster에서 catalog lookup 비용과 session reuse 패턴이 중요하다.

아직 기다리는 편이 나은 경우

• 전체 환경이 아직 v26.33으로 정렬되지 않았다.
• metadata DB가 PostgreSQL이 아니다.
• 최근 major/minor upgrade 직후라, 먼저 baseline 안정화를 끝내야 한다.
• connection/session 재사용 방식이 복잡해 catalog snapshot cache의 효과와 부작용을 먼저 분리해서 보고 싶다.

실제 검증 순서

1. 배포 형태 확인

- Cloud / Self-Managed 구분 - Self-Managed라면 metadata DB 종류 확인

1. 업그레이드 경로 확인

- general upgrading guide로 operator 선행 업그레이드, major-version hop 제한 확인 - version notes로 v26.33 경계 확인

1. 기능 활성화 전 baseline

- metadata-heavy 작업 시간대의 체감 latency - query-heavy cluster의 세션 reuse 패턴 - EXPLAIN TIMESTAMP / SUBSCRIBE 가 영향받는지 incident 기록 검토

1. v26.33 정렬 후 기능 활성화

- persist_pg_consensus_read_committed 적용 - Postgres metadata DB에만 적용했는지 재확인

1. 롤아웃 후 비교

- control-plane write contention 감소 여부 - query-heavy cluster의 catalog lookup 체감 - MCP replica 고정 EXPLAIN ANALYZE 로 replica별 편차가 줄었는지 확인

1. Cloud 환경이라면 별도 체크

- hydration time 개선은 공식 수치가 아니라 자기 워크로드 재측정값 으로 판단

한 줄 결론

Materialize v26.33의 진짜 의미는 "조금 더 빨라진 릴리스"가 아니다. 메타데이터 DB 격리 수준, 세션 카탈로그 캐시, timestamp oracle stall 분리, replica별 진단 을 한 방향으로 묶어, query-heavy cluster와 self-managed control plane에서 어디가 먼저 막히는지 를 바꾸는 릴리스다.

Self-Managed + PostgreSQL metadata DB 팀이라면 이건 성능 튜닝 팁이 아니라 공식 지원되는 운영 경계의 확장 으로 읽는 편이 맞다. 반대로 Cloud-only 팀이라면 이번 릴리스의 핵심은 손댈 파라미터보다, hydration과 busy-cluster latency가 실제로 얼마나 달라졌는지 재측정하는 데 있다.

References

• Materialize Docs — Releases / v26.33.0 (released to Cloud 2026-07-16, Self-Managed 2026-07-17): https://materialize.com/docs/releases/
• Materialize Docs — Self-Managed Deployments / Upgrading / Version notes (persist_pg_consensus_read_committed, READ COMMITTED, linearizable consensus query guidance): https://materialize.com/docs/self-managed-deployments/upgrading/version-notes/
• Materialize Docs — Self-Managed Deployments / Upgrading (operator-first upgrade rule and major-version hop rule): https://materialize.com/docs/self-managed-deployments/upgrading/
• GitHub Releases — MaterializeInc/materialize v26.33.0 (release timestamp and release artifact trail): https://github.com/MaterializeInc/materialize/releases/tag/v26.33.0