LLM WikiAccess-protected knowledge portal

WIKI

RisingWave 3.0: SQL 운영면과 DataFusion 기본화로 스트리밍 DB의 경계를 넓힌 방식

왜 지금 RisingWave 3.0을 봐야 하나 RisingWave 3.0은 2026년 6월 11일 공개됐다. 2026년 7월 20일 기준으로 공개 39일째인, 아직 90일 창 안에 있는 비교적 신선한 릴리스다. 이번 버전의 핵심은 기능 목록이 길어졌다는 사실보다 스트리밍 데이터베이스를 "실시간 쿼리 엔진"에서 "운영 가능한 데이터 플랫폼"으로 밀어 올리는 변화가 한 번에 들어왔다는 점 에 있다. 운영자 관점에서 중요한 축은

경로human/study/content/database-frontier/27-risingwave-3-0-sql-control-plane-datafusion.md
카테고리Study
태그#ai-review #control #datafusion #mysql #plane #risingwave #sql #study

왜 지금 RisingWave 3.0을 봐야 하나

RisingWave 3.0은 2026년 6월 11일 공개됐다. 2026년 7월 20일 기준으로 공개 39일째인, 아직 90일 창 안에 있는 비교적 신선한 릴리스다. 이번 버전의 핵심은 기능 목록이 길어졌다는 사실보다 스트리밍 데이터베이스를 "실시간 쿼리 엔진"에서 "운영 가능한 데이터 플랫폼"으로 밀어 올리는 변화가 한 번에 들어왔다는 점에 있다.

운영자 관점에서 중요한 축은 세 가지다.

  1. SQL이 운영 인터페이스가 되기 시작했다. BACKUP, DELETE META SNAPSHOT, ALTER SUBSCRIPTION ... SET (retention = ...), CDC 자격 증명 회전 같은 작업이 SQL 표면으로 올라왔다.
  2. 배치 경로가 바뀌었다. Apache DataFusion이 배치 쿼리 기본 엔진이 되고, materialized view 재사용 경로가 늘어나면서 같은 SQL이라도 실행 경로가 달라질 수 있다.
  3. 스트리밍과 Lakehouse의 연결이 더 가까워졌다. Iceberg 통합, pgvector ingestion, 커넥터 확장, subscription 개선이 한 릴리스에서 묶였다.

즉, RisingWave 3.0은 “스트리밍 SQL이 조금 더 좋아졌다”는 릴리스가 아니라 데이터 수집·상태 유지·배치 분석·운영 자동화를 같은 제어면에서 다루려는 시도로 읽는 편이 맞다.

한눈에 보는 3.0 변화

영역3.0에서 눈에 띄는 변화운영자가 신경 써야 할 것
운영 제어면BACKUP, DELETE META SNAPSHOT, SHOW CURSORS, subscription retention 변경, CDC password rotation기존 risectl/스크립트 의존 작업을 SQL로 옮길 수 있는지, 권한과 감사 경로를 어떻게 남길지
배치 실행DataFusion 기본화, materialized view selection 확장plan regression, 메모리 사용량, 배치 쿼리와 MV 재사용 여부를 카나리로 검증해야 함
Lakehouse/수집Iceberg V3·internal/external Iceberg 경로, pgvector ingestion, WebSocket/HTTP connector, CDC 개선실시간 수집과 분석 저장소를 한 플랫폼에서 다루되, 커넥터별 exactly-once/운영 보장 범위를 개별 확인해야 함
관측성richer system catalog, connector metrics, cursor/subscription surface어떤 지표가 SQL 카탈로그에서 보이고 어떤 항목은 여전히 외부 대시보드가 필요한지 구분해야 함
RisingWave 3.0: SQL 제어면 위에 배치·스트리밍·Lakehouse를 겹치는 구조 제어면: PostgreSQL 호환 SQL 클라이언트 / 자동화 psql · app · agent · CI Serving Node SQL parse/plan · batch query · PG wire Meta Node job lifecycle · metadata · backup snapshot 운영 SQL 표면 BACKUP · SHOW CURSORS · ALTER ... 3.0의 포인트: 운영 작업이 CLI/외부 스크립트에서 SQL 제어면으로 올라오고, 배치·스트리밍 경로가 같은 플랫폼 안에서 더 촘촘히 연결된다. 데이터면: 배치·스트리밍·Lakehouse 실행 경로 Batch path DataFusion default MV selection / ad-hoc analytics Streaming path Streaming Node stateful compute / backfill / checkpoint State & storage Hummock state + object storage Compactor / snapshot / backup Iceberg / external internal tables source / sink / lakehouse 운영자가 실제로 확인해야 할 것은 기능 추가 자체보다 "어느 경로가 기본값이 되었는가"와 "어떤 작업이 SQL 제어면으로 옮겨왔는가"다. 3.0에서는 배치 엔진 기본값, MV 재사용, backup 표면, connector rotation, subscription retention 같은 항목이 바로 그 경계에 있다.
RisingWave 3.0 제어면과 데이터면

아키텍처 관점: 3.0 변화는 어디에 꽂히는가

RisingWave 공식 아키텍처 문서는 클러스터를 네 노드로 나눈다.

또한 영속 데이터는 S3/GCS/Azure Blob 같은 오브젝트 스토리지에 놓인다. 이 구조를 기준으로 보면 3.0의 변화는 다음처럼 해석된다.

  1. DataFusion 기본화는 Serving Node의 batch path에 직접 꽂히는 변화다.
  2. BACKUP / meta snapshot 삭제는 Meta Node 제어면을 SQL 표면으로 끌어올리는 변화다.
  3. backfill parallelism 조정은 Streaming Node와 Meta Node 사이의 재스케줄링 경로를 건드린다.
  4. Iceberg integration 강화는 Storage/Lakehouse 쪽 연결면을 키운 변화다.

이 관점이 중요한 이유는, 릴리스 노트에 같은 줄로 적혀 있더라도 어떤 변화는 SQL 파서 레벨이고, 어떤 변화는 optimizer이고, 어떤 변화는 runtime/reschedule path이기 때문이다. 업그레이드 후 장애 양상도 축마다 다르게 나타난다.

SQL이 운영 인터페이스가 되기 시작했다

3.0에서 가장 흥미로운 변화는 “운영 작업을 SQL로 수행한다”는 방향이 선명해졌다는 점이다. 공식 블로그는 이 릴리스에서 SQL이 단순 조회 언어를 넘어 backup, schema evolution, connector management, pipeline operations의 인터페이스가 된다고 설명한다.

릴리스 노트와 관련 PR을 합치면 대표 사례는 다음과 같다.

BACKUP;
DELETE META SNAPSHOT 1042;
ALTER SUBSCRIPTION fraud_feed SET (retention = '7d');
ALTER SOURCE orders_cdc CONNECTOR WITH ('password' = 'rotated-secret');
ALTER MATERIALIZED VIEW mv_orders SET backfill_parallelism = 8;
SHOW CURSORS;

이 표면이 왜 중요한가를 항목별로 보면 더 분명하다.

1) BACKUP이 SQL로 올라왔다

PR #25042에 따르면 BACKUP은 이제 SQL로 파싱·실행되며, 백업 작업이 끝날 때까지 기다린 뒤 생성된 snapshot_id를 결과로 반환한다. 그리고 DELETE META SNAPSHOT <id> / DELETE META SNAPSHOTS ... 명령도 기존 meta snapshot 삭제 RPC에 연결됐다.

운영 의미는 단순하다.

즉, 메타데이터 보호가 도구 외부의 별도 절차에서 데이터베이스 내부의 관리 명령으로 한 단계 흡수된 셈이다.

2) subscription retention 변경이 운영 루프로 들어왔다

공식 subscription 문서는 retention window를 명시하고, 이 창을 지나면 incremental data를 다시 읽을 수 없다고 적는다. 3.0 release note는 여기에 ALTER SUBSCRIPTION ... SET (retention = ...)를 추가한다.

이 변화는 “subscription을 만들 때 retention을 한 번 정하고 끝”이 아니라는 뜻이다. 실제 운영에서는 소비자 재기동, 장애 복구 시간, 다운스트림 배치 주기가 바뀌면서 retention 요구치도 바뀐다. 이때 subscription을 재생성하지 않고 retention을 조정할 수 있다는 것은 꽤 큰 차이다.

3) CDC password rotation이 재생성 없는 경로로 들어왔다

PR #25435는 PostgreSQL/MySQL/SQL Server CDC source에 대해 ALTER SOURCE ... CONNECTOR WITH (password = ...) 형태의 자격 증명 회전을 허용한다고 설명한다. 즉, 비밀번호가 바뀌었다고 source를 다시 만들고 백필을 다시 태우는 경로를 피할 수 있다.

운영에서 이건 꽤 현실적인 이점이다.

4) backfill parallelism이 런타임 조정 대상으로 올라왔다

PR #24323은 ALTER MATERIALIZED VIEW ... SET backfill_parallelism = n 예시를 포함한다. 구현 설명을 보면 Meta service, DDL gRPC, reschedule path, deferred execution mode까지 건드린다.

이 뜻은 명확하다. RisingWave는 backfill을 더 이상 “처음 만들 때 정한 병렬도대로 끝까지 간다”는 고정 경로로만 보지 않는다. 운영자는 초기 적재 구간의 리소스 사용량을 별도로 조정할 수 있다.

이 기능이 특히 중요한 경우는 다음과 같다.

배치 경로: DataFusion이 기본값이 되면서 달라지는 것

RisingWave 아키텍처 문서는 Serving Node가 batch query를 직접 처리한다고 설명한다. 따라서 DataFusion 기본화는 storage engine의 변화가 아니라 batch execution path의 기본값 전환이다.

PR #25198는 enable_datafusion_engine의 기본값을 true로 바꿨다고 명시한다. 공식 블로그도 3.0의 큰 변화 중 하나로 “Apache DataFusion is now the default execution engine for batch queries”를 꼽는다.

운영자가 봐야 할 포인트는 두 가지다.

1) 성능보다 먼저, 계획 차이를 봐야 한다

기본값 전환은 같은 SQL이 이제 다른 엔진을 지나간다는 의미다. 공식 블로그는 SQL 호환성, 메모리 관리, analytical performance 개선을 강조하지만, 운영자가 실제로 확인해야 하는 것은 기존 batch query의 실행 계획과 메모리 사용량이 어떻게 달라졌는가다.

특히 아래 항목은 카나리로 봐야 한다.

DataFusion 자체가 좋아졌다는 말과 내 워크로드에서 regression이 없다는 말은 다르다.

2) materialized view 재사용이 더 실전적으로 바뀌었다

3.0 릴리스 노트는 batch query가 equivalent pre-computed MV를 자동으로 사용할 수 있다고 요약한다. 소스 PR을 보면 이 기능은 단계적으로 확장됐다.

이 조합이 의미하는 바는 단순한 exact match substitution을 넘어선다는 점이다. 같은 결과를 낼 수 있는 사전 계산 MV가 있으면, optimizer가 이를 배치 쿼리에 재사용하는 방향으로 확장되고 있다.

다만 여기에는 주의점도 있다.

즉, RisingWave 3.0의 MV selection은 “개념 검증” 단계를 넘었지만, 운영 표면에서는 버전별 기본값과 매칭 범위를 따로 검증해야 하는 기능이다.

Lakehouse와 수집 경로: 스트리밍 엔진을 저장소 앞단으로 세운다

공식 Iceberg 문서는 RisingWave를 “streaming lakehouse with native Apache Iceberg support”라고 정의한다. 여기서 중요한 것은 단순히 Iceberg connector가 있다는 뜻이 아니라, internal Iceberg tables와 external Iceberg source/sink를 분리해 사고한다는 점이다.

모드의미운영 포인트
Internal Iceberg tablesRisingWave가 catalog, compaction, ingestion lifecycle을 관리편하지만, catalog/compaction 정책도 RisingWave 운영 범위 안에 들어온다
External Iceberg source/sink외부에서 관리하는 Iceberg 테이블과 데이터 교환멀티엔진 상호운용성은 좋지만, catalog consistency와 권한 설계는 외부 시스템과 같이 봐야 한다

RisingWave 공식 블로그가 Iceberg V3, pgvector ingestion, WebSocket/HTTP connector, exactly-once delivery를 함께 묶는 이유도 여기에 있다. 이 조합은 RisingWave를 “스트리밍 SQL 엔진”이 아니라 실시간 컨텍스트를 모으고, 가공하고, Lakehouse/서비스로 내보내는 허브로 보겠다는 선언에 가깝다.

운영자에게 번역하면 다음과 같다.

3.0의 진짜 함정: 문서 표면이 아직 완전히 따라오지 않았다

이번 릴리스에서 특히 운영자다운 포인트는 기능 자체보다 문서 표면의 지연이다. 실제로 공식 문서 몇 곳을 보면 release note와 완전히 맞물리지 않는다.

항목release note / PR에서 보이는 표면현재 문서에서 보이는 표면운영 해석
CDC password rotationPR #25435: Postgres/MySQL/SQL Server CDC source에서 ALTER SOURCE ... CONNECTOR WITH (password = ...) 지원ALTER SOURCE 문서는 아직 “We currently support altering Kafka connectors only”라고 적음배포 버전과 문서 버전이 어긋날 수 있으니 staging에서 실제 syntax를 먼저 검증해야 함
subscription retention 변경release note: ALTER SUBSCRIPTION ... SET (retention = ...)ALTER SUBSCRIPTION 문서는 OWNER TO, RENAME TO, SET SCHEMA, SWAP WITH만 설명운영 런북을 문서만 보고 쓰면 retention 조정 기능을 놓칠 수 있음
cursor surfacerelease note: cluster 전 frontend node에서 SHOW CURSORS와 subscription cursor 지원 강화SHOW CURSORS 문서는 “current session의 cursor 표시” 예시만 제공single-node mental model로 운영 문서를 쓰면 분산 환경 가시성을 과소평가할 수 있음

이건 단순한 문서 품질 비판이 아니다. SQL 제어면이 빠르게 확장되는 제품에서는 release note, PR, reference docs가 잠깐씩 다른 속도로 움직이는 구간이 생긴다. 운영자는 이 구간에서 “문서에 안 나와 있으니 기능이 없다”고 결론 내리면 안 되고, 반대로 “release note에 있으니 바로 production에 넣자”고 가도 안 된다.

정답은 항상 같다.

  1. 배포한 이미지의 버전 확인
  2. staging에서 syntax 검증
  3. 권한/감사 로그 확인
  4. 기존 자동화 치환 여부 검토

업그레이드 전에 확인할 것

1) 배치 쿼리 카나리

체크 항목왜 필요한가
대표 analytical query의 EXPLAIN/지연 시간 비교DataFusion 기본화로 plan 경로가 달라질 수 있기 때문
메모리·spill 관련 지표DataFusion OOM handling과 reserve headroom 개선이 실제 워크로드에서 어떻게 보이는지 확인해야 하기 때문
MV 재사용 유무기대한 MV selection이 실제로 켜졌는지, 또는 지나친 rewrite가 없는지 확인해야 하기 때문

2) 운영 SQL 카나리

체크 항목왜 필요한가
BACKUP; 실행과 snapshot id 반환기존 backup 자동화를 SQL 기반으로 옮길 수 있는지 확인
DELETE META SNAPSHOT 권한superuser/관리 권한 경계가 적절한지 확인
ALTER SUBSCRIPTION ... SET (retention = ...)복구 런북을 recreate 없이 바꿀 수 있는지 확인
ALTER SOURCE ... CONNECTOR WITHcredential rotation이 source recreation 없이 되는지 확인
SHOW CURSORS다중 frontend 환경에서 실제 노출 범위를 확인

3) 데이터 경로 카나리

체크 항목왜 필요한가
CDC lag와 connector metricsrelease note가 말하는 observability 개선이 실제 대시보드/카탈로그에서 보이는지 확인
internal vs external Iceberg 구분compaction과 catalog ownership이 누구 책임인지 선명히 하기 위해
subscription retention 저장 비용복구 시간 확대와 저장 비용 증가를 같이 계산해야 하기 때문

누구에게 특히 중요한 릴리스인가

RisingWave 3.0은 모든 팀에게 똑같이 중요하지는 않다. 특히 다음 조건에 해당하면 우선순위가 올라간다.

반대로, RisingWave를 아직 단일 목적의 스트리밍 SQL 엔진 정도로만 쓰고 있다면 3.0의 장점이 과하게 느껴질 수도 있다. 이 경우엔 모든 표면을 한꺼번에 쓰려 하지 말고, 배치 path와 운영 SQL path를 따로 카나리하는 편이 안전하다.

결론

RisingWave 3.0의 본질은 새 커넥터 몇 개가 추가된 것이 아니다. SQL로 운영하고, DataFusion으로 배치 처리하고, Iceberg로 외부 분석 저장소를 잇는 세 축이 한 플랫폼 안에서 더 강하게 연결된 것이 핵심이다.

이 연결은 분명 강력하다. 하지만 동시에 운영자가 확인해야 할 경계도 늘어난다.

그래서 3.0을 도입할 때의 질문은 “기능이 많은가?”가 아니라 아래에 가깝다.

우리 팀은 이제 스트리밍 시스템을 쿼리만 하는가, 아니면 SQL로 운영까지 하려는가?

RisingWave 3.0은 후자에 훨씬 가까운 답을 내놓은 릴리스다.

References