OLAP DB 시장과 StarRocks 포지션

한 줄 요약

StarRocks는 전체 분석 DB 매출 시장의 주류는 아니지만, 실시간 분석 서빙, 복잡한 JOIN, 레이크하우스 가속, 고동시성 대시보드 같은 좁고 까다로운 워크로드에서는 검토할 만한 오픈소스 OLAP 엔진이다.

먼저 읽을 결론

“OLAP DB 시장점유율”은 하나의 숫자로 말하기 어렵다. Snowflake, Databricks, BigQuery, Redshift, Synapse/Fabric, ClickHouse, Trino, Druid, Pinot, StarRocks는 모두 분석 DB 후보로 묶이지만 실제 시장은 클라우드 데이터웨어하우스, 레이크하우스, 실시간 OLAP, 페더레이션 쿼리 엔진, 임베디드 분석 DB로 갈라진다.

그래서 이 주제는 매출, 도입률, DB-Engines 인지도, 오픈소스 커뮤니티, 고객 사례를 나눠 봐야 한다.

관점	현재 구도
전체 DBMS 시장	Gartner 기준 2024년 전 세계 DBMS 시장은 1,197억 달러였고, 클라우드 DBMS 지출 비중은 64%였다. 2026년 시장 전망은 1,610억 달러다.
매출 기준 분석 DB	Snowflake, Databricks, AWS, Google, Microsoft 같은 대형 플랫폼이 주도한다.
실시간 OLAP	ClickHouse가 상업적 규모와 인지도에서 앞서 있다. 2026년 5월 기준 ClickHouse는 2.5억 달러 ARR를 공개했다.
StarRocks	공개 매출이나 정확한 시장점유율은 없다. DB-Engines 2026년 7월 기준 전체 DBMS 143위, 점수 1.61이다.
현실적 포지션	“차세대 Snowflake”라기보다 고성능 실시간 분석 서빙 레이어에 가깝다.

StarRocks의 핵심 강점은 컬럼 저장, 완전 벡터화 실행, SIMD, MPP, CBO, 물질화뷰 자동 rewrite, 외부 레이크하우스 테이블 가속, Primary Key table 기반 업데이트 처리다. 단일 기능 하나가 아니라 여러 레이어가 맞물려 빠르다.

다만 StarRocks의 점유율을 강하게 말하면 안 된다. 공개 자료로 확인되는 것은 “아직 롱테일이지만, 특정 실시간 OLAP 워크로드에서는 눈에 띄는 challenger”라는 정도다.

왜 저장했나

데이터 플랫폼을 고를 때 “빠른 OLAP DB”라는 말은 너무 넓다. Snowflake와 ClickHouse, Trino, Druid, StarRocks는 같은 표에서 비교되지만 구매 이유와 강점이 다르다.

이 노트는 StarRocks를 과장 없이 평가하기 위한 기준점이다. 특히 다음 질문에 답한다.

OLAP DB 시장점유율을 어떤 지표로 봐야 하는가?
StarRocks의 점유율은 공개 자료로 얼마나 말할 수 있는가?
StarRocks는 왜 빠른가?
ClickHouse, Trino, Druid, Pinot, Snowflake, Databricks와 어떻게 다르게 봐야 하는가?
어떤 워크로드에서 POC할 가치가 있고, 어떤 경우에는 다른 엔진이 나은가?

정리한 질문

2026년 7월 기준으로 OLAP/분석 DB 시장을 매출, 도입률, 인지도, 기술 채택 신호로 나누면 어떤 구도가 보이는가? 그 안에서 StarRocks의 점유율과 포지션은 어느 정도이며, 성능이 빠른 이유와 향후 전망은 무엇인가?

시장을 나누는 방식

OLAP DB를 좁게 보면 대량 데이터를 컬럼 기반으로 저장하고 집계, 필터, JOIN, 다차원 분석을 빠르게 수행하는 DB다. 실제 구매 시장은 더 복잡하다.

세그먼트	대표 제품	주된 구매 이유
클라우드 데이터웨어하우스	Snowflake, BigQuery, Redshift, Synapse/Fabric	범용 BI, ELT, 거버넌스, SaaS 운영 편의성
레이크하우스	Databricks, Iceberg 기반 엔진, StarRocks lakehouse mode	오픈 포맷, ML/AI, 데이터레이크 직접 분석
실시간 OLAP / 서빙 분석	ClickHouse, Druid, Pinot, StarRocks	대시보드, 이벤트 분석, 고객-facing analytics, 저지연
페더레이션 쿼리 엔진	Trino/Presto	여러 데이터 소스에 대한 SQL 쿼리, 데이터 복사 최소화
임베디드/로컬 분석	DuckDB 등	개발자 분석, 로컬 분석, 앱 내 경량 처리

이 구분 때문에 시장점유율을 하나로 말하면 왜곡된다. 매출 점유율은 대형 클라우드 플랫폼 중심으로 봐야 하고, 기술 채택 신호는 DB-Engines, GitHub, 고객 사례, 커뮤니티 지표까지 함께 봐야 한다.

공개 지표로 본 시장 구도

공개 숫자만 보면 분석 DB 시장의 상단은 Snowflake와 Databricks, 그리고 대형 클라우드 벤더 쪽에 있다.

Snowflake는 FY2026 4분기에 매출 12.8억 달러, 제품 매출 12.3억 달러, 100만 달러 이상 TTM 제품 매출 고객 733곳을 발표했다. Databricks는 2025년 12월 기준 revenue run-rate 48억 달러 이상, 2026년 2월에는 54억 달러 이상을 발표했다. Databricks는 데이터웨어하우징 제품도 10억 달러 run-rate 이상이라고 밝혔다.

ClickHouse도 단순 오픈소스 프로젝트 단계는 지났다. 2026년 5월 ClickHouse는 2.5억 달러 ARR와 4,000개 고객을 공개했다. 실시간 OLAP 세그먼트에서 ClickHouse가 상업적 규모를 확보했다는 신호다.

반면 StarRocks/CelerData는 공개 매출, ARR, 고객 수, 클라우드 사용량을 정량적으로 공개하지 않는다. 그래서 “StarRocks 시장점유율은 몇 %”라고 쓰기는 어렵다. Snowflake와 Databricks가 수십억 달러 규모를 공개하고, ClickHouse가 수억 달러 ARR를 공개한 반면 StarRocks에는 같은 급의 공개 지표가 없다. 전체 DBMS나 클라우드 데이터웨어하우스 매출 기준으로는 1% 미만의 롱테일 플레이어일 가능성이 높다는 추정만 가능하다.

DB-Engines로 본 StarRocks

DB-Engines는 설치 수나 매출이 아니라 검색량, 기술 토론, 채용, 프로필, 소셜 신호 등을 섞어 인기도를 집계한다. 2026년 7월 기준 주요 분석 DB 관련 제품의 위치는 다음과 같다.

제품	DB-Engines 2026년 7월 순위 / 점수	해석
Snowflake	6위 / 216.06	클라우드 DW 대표주자
Databricks	7위 / 164.08	레이크하우스·AI 플랫폼 강자
BigQuery	19위 / 53.08	Google Cloud 기본 분석 플랫폼
ClickHouse	26위 / 25.27	오픈소스 실시간 OLAP 최상위권
Azure Synapse	35위 / 16.59	Microsoft 분석 플랫폼 축
Redshift	36위 / 16.44	AWS DW
DuckDB	42위 / 10.41	로컬/임베디드 분석 급성장
Trino	53위 / 7.24	페더레이션 SQL 엔진
Apache Druid	76위 / 3.77	실시간 이벤트/시계열 OLAP
StarRocks	143위 / 1.61	신흥 고성능 OLAP 엔진
Firebolt	235위 / 0.56	클라우드 OLAP
Apache Pinot	236위 / 0.56	실시간 서빙 OLAP

StarRocks의 DB-Engines 점수 1.61은 ClickHouse의 약 6.4%, Druid의 약 42.7%, Trino의 약 22.2%다. 이 비율은 시장점유율이 아니라 공개 인지도/관심도의 프록시다. 그래도 방향은 읽을 수 있다. StarRocks는 ClickHouse급 대중성에는 아직 멀지만, Pinot나 Firebolt보다 높은 공개 인지도 신호를 보인다.

StarRocks의 실제 포지션

StarRocks는 Snowflake나 Databricks처럼 전사 표준 데이터 플랫폼으로 먼저 팔리는 제품이라기보다, 특정 성능 병목을 해결하는 엔진에 가깝다.

강한 후보가 되는 상황은 대체로 네 가지다.

Trino/Presto로는 대시보드 latency가 높거나 JOIN이 무거운 경우
ClickHouse, Druid, Pinot에서 데이터 모델을 과도하게 denormalize해야 하는 경우
Iceberg, Hive, Hudi, Delta Lake 위 데이터를 빠르게 서빙해야 하는 경우
실시간 CDC 업데이트와 분석 쿼리를 한 엔진에서 처리해야 하는 경우

이 포지션은 시장 전체로 보면 작지만, 특정 워크로드에서는 강하다. StarRocks는 대형 DW 시장의 점유율 플레이어라기보다 고성능 실시간 분석 워크로드의 기술 침투 플레이어로 보는 편이 정확하다.

StarRocks가 빠른 이유

StarRocks의 성능 강점은 단일 기능이 아니라 실행 엔진, 분산 처리, 최적화기, 캐시, 물질화뷰, 업데이트 모델이 함께 움직인 결과다.

컬럼 저장, 벡터화 실행, SIMD

StarRocks는 컬럼 기반 저장·계산 구조와 완전 벡터화 실행 엔진을 쓴다. 공식 문서는 벡터화 엔진이 CPU cache 활용을 높이고 가상 함수 호출과 분기를 줄이며 SIMD 명령을 활용해 operator 성능을 3~10배 높인다고 설명한다.

encoded data에 대해 JOIN, aggregation, expression 계산을 수행할 수 있다는 점도 중요하다. 일부 string 연산에서 decode 비용을 줄이면 CPU 사용량과 latency가 크게 줄어든다. 컬럼형 저장은 필요한 컬럼만 읽게 해 I/O와 압축 효율에서도 유리하다.

MPP와 분산 병렬 처리

StarRocks는 MPP 구조로 여러 노드에서 scan, JOIN, aggregate를 병렬 수행한다. 큰 fact table과 여러 dimension table을 조합하는 BI/OLAP 쿼리에서는 단일 노드 성능보다 분산 plan, shuffle, local aggregation 품질이 병목을 좌우한다.

CBO와 복잡한 JOIN

StarRocks가 강조하는 차별점 중 하나는 multi-table JOIN을 겨냥한 Cost-Based Optimizer다. CBO는 logical plan에서 여러 physical plan을 만들고 CPU, 메모리, 네트워크, I/O 비용을 추정해 실행 계획을 고른다. 문서상 v2.4부터 histogram, v3.2부터 Hive/Iceberg/Hudi 통계 수집을 지원한다.

JOIN order 하나가 틀리면 중간 결과가 폭증하고 네트워크 shuffle과 메모리 사용량이 커진다. StarRocks는 이 지점에서 “flat table만 빠른 DB”가 아니라 정규화된 모델과 복잡한 JOIN까지 빠르게 처리하는 OLAP DB를 지향한다.

물질화뷰 자동 rewrite

StarRocks의 asynchronous materialized view는 precomputed result를 이용해 원본 테이블 쿼리를 자동 rewrite할 수 있다. 대시보드 쿼리는 반복적이고 특정 dimension·metric 조합이 자주 호출된다. 매번 원본 fact table을 scan하고 JOIN하는 대신 물질화뷰가 맞으면 latency와 compute cost를 크게 줄인다.

레이크하우스 가속

StarRocks는 Hudi, Iceberg, Delta Lake, Hive 등 외부 catalog를 통해 데이터레이크 데이터를 직접 쿼리할 수 있다. 다만 S3 같은 object storage 위 쿼리는 remote I/O와 네트워크 latency가 문제다.

StarRocks는 Data Cache와 materialized view로 이 문제를 줄인다. 공식 문서에 따르면 Data Cache는 v3.3부터 기본 활성화됐고, v4.0에서는 memory+disk unified cache를 제공한다. 방향은 “모든 데이터를 StarRocks로 복사하라”가 아니라, open table format을 직접 읽되 hot data와 반복 쿼리는 캐시와 MV로 가속하는 쪽이다.

Primary Key table과 실시간 업데이트

OLAP DB는 append-only에는 강하지만 update/delete에는 약한 경우가 많다. StarRocks의 Primary Key table은 실시간 add/delete/update, partial column update를 지원한다. 공식 문서는 Unique Key table의 Merge-On-Read 대비 query performance가 3~10배 높을 수 있다고 설명한다.

이 기능은 CDC 기반 운영 데이터 분석에서 의미가 크다. 주문 상태, 사용자 프로필, 재고, 광고 캠페인 상태처럼 계속 바뀌는 데이터를 분석할 때 full refresh나 무거운 merge-on-read는 latency와 비용을 키운다.

Resource Group과 고동시성 운영

실시간 대시보드, 운영 리포트, ad hoc 분석, batch job이 같은 클러스터를 쓰면 heavy query 하나가 서비스성 쿼리를 밀어낼 수 있다. StarRocks는 resource group으로 compute resource를 나누고 CPU·메모리 quota, exclusive CPU core, concurrency limit을 설정할 수 있다.

Toss Shopping 사례는 이 문제를 잘 보여준다. 분당 약 1,500건의 service request 상황에서 exclusive_cpu_cores 기반 자원 분리를 적용해 latency spike를 줄였다고 설명한다.

벤치마크와 사례 해석

StarRocks 공식 TPC-H 100GB 벤치마크에서는 22개 쿼리 총합 기준 StarRocks native가 약 21초, StarRocks Hive external table이 약 92초, Trino가 약 187초로 제시된다. 테스트 환경은 4개 host, 16-core Intel Xeon, 64GB memory, StarRocks 3.0 CE, Trino 419, Hive 2.3.9다.

Shopee 사례에서는 Presto 대비 외부 Hive table JOIN query에서 3~~10배 성능 개선, 온라인 비즈니스 쿼리에서 평균 3~~10배 개선과 60% CPU 절감이 보고됐다. 같은 리소스 조건의 테스트에서는 StarRocks가 Presto보다 2~3배 빠르고, 50% 리소스로 유사한 계산 능력을 보였다고 설명한다.

이 숫자는 StarRocks가 항상 빠르다는 뜻이 아니다. 벤더 벤치마크와 고객 사례는 대개 제품이 강한 조건을 잘 보여준다. 실제 POC에서는 대표 쿼리와 데이터 모델을 직접 가져와야 한다.

잘 맞는 워크로드와 덜 맞는 워크로드

StarRocks가 강한 조건은 비교적 분명하다.

상황	StarRocks 적합도
고객-facing dashboard에서 P95/P99 latency가 중요함	높음
실시간 CDC 데이터에 대해 SQL 분석이 필요함	높음
multi-table JOIN이 많아 ClickHouse/Pinot/Druid 모델링이 부담됨	높음
Trino/Presto latency 또는 CPU 비용이 문제임	높음
Iceberg/Hive/Hudi/Delta 위 데이터를 빠르게 서빙해야 함	중~높음
Snowflake/Databricks 비용 중 일부 serving workload를 offload하고 싶음	중~높음
전사 거버넌스·마켓플레이스·데이터 공유 중심 DW가 필요함	낮음~중간
순수 OLTP 트랜잭션 DB가 필요함	낮음
검색/로그 전문 쿼리가 핵심임	Elasticsearch/OpenSearch/Splunk/ClickHouse 등과 비교 필요

아주 단순한 append-only log scan, 초고속 single-table aggregation, 순수 검색, 순수 OLTP에서는 다른 엔진이 더 나을 수 있다. ClickHouse, Druid, Pinot처럼 특정 워크로드에 깊게 최적화된 엔진도 반드시 비교해야 한다.

경쟁 구도

제품군	강점	StarRocks와의 관계
Snowflake	SaaS DW, 거버넌스, 보안, 데이터 공유, 생태계	전사 DW 전체 대체보다는 고동시성·저지연 serving layer로 보완 또는 일부 대체
Databricks	Lakehouse, Spark, ML/AI, Unity Catalog, Delta 생태계	lakehouse 위 interactive SQL 가속 엔진으로 경쟁/보완
BigQuery / Redshift / Synapse/Fabric	클라우드 기본 통합, 운영 편의성	클라우드 종속 조직의 기본 선택지. StarRocks는 비용·latency 이슈가 있을 때 후보
ClickHouse	로그·이벤트·시계열, single-table 분석, 빠른 scan/aggregation, 큰 커뮤니티	StarRocks는 복잡 JOIN, update, MV rewrite, lakehouse SQL에서 차별화 시도
Trino/Presto	여러 데이터 소스 federation, SQL layer	StarRocks는 cache/MV/optimizer/storage 연계로 더 낮은 latency를 노림
Druid/Pinot	실시간 ingestion, event serving analytics, high QPS	StarRocks는 더 일반적인 SQL/JOIN/update 모델을 주장
DuckDB	로컬·임베디드 분석, 개발자 경험	직접 경쟁보다 별도 성장 축

전망

StarRocks에 유리한 흐름은 세 가지다.

첫째, AI agent와 embedded analytics가 늘면 분석 DB에 들어가는 쿼리 수와 동시성이 늘어난다. 사용자가 대시보드 하나를 클릭하는 것과 달리, agent는 schema 탐색, metric 후보 생성, drill-down, anomaly query, validation query를 연속 또는 병렬로 날릴 수 있다. 이때 병목은 모델 추론만이 아니라 분석 DB의 query concurrency와 latency가 된다.

둘째, Iceberg와 open lakehouse 확산은 StarRocks 같은 엔진에 기회를 준다. 기업이 데이터레이크에 open table format을 더 많이 쌓을수록, 데이터를 전부 복사하지 않고 빠르게 읽고 캐시하고 물질화뷰로 가속하는 SQL 엔진의 수요가 생긴다.

셋째, 비용 절감 수요가 있다. Snowflake, Databricks, BigQuery, Redshift는 운영 편의성이 높지만, 고동시성 대시보드나 customer-facing analytics에서는 비용이 커질 수 있다. 기존 데이터 플랫폼은 유지하되 serving analytics만 분리하려는 조직에는 StarRocks가 후보가 된다.

그래도 전망은 보수적으로 잡아야 한다. 전체 DBMS 매출 시장에서는 당분간 롱테일이다. 오픈소스 실시간 OLAP/레이크하우스 가속 시장에서는 주목할 만한 challenger다. 복잡 JOIN과 real-time serving analytics가 핵심인 조직에서는 ClickHouse, Trino, Druid, Pinot와 함께 POC할 후보로 보는 것이 현실적이다.

POC 체크리스트

StarRocks POC는 평균 latency만 보면 실패한다. 최소한 다음 지표를 함께 봐야 한다.

POC 항목	봐야 할 지표
복잡 JOIN 쿼리	P50/P95/P99 latency, spill, network shuffle, join order
동시성	QPS, queue time, timeout rate, resource group 효과
실시간 업데이트	freshness lag, update throughput, compaction 영향
레이크하우스 쿼리	cold cache vs warm cache, remote I/O, cache hit ratio
물질화뷰	rewrite hit rate, refresh cost, staleness 허용 범위
비용	core-hour, storage, object storage GET 비용, 운영 인력
안정성	failover, rebalance, scaling, schema evolution, backup/restore

POC의 결론도 “빠르다/느리다”가 아니라 다음처럼 나와야 한다.

어떤 쿼리 패턴에서 빠른가?
어떤 데이터 모델에서는 모델링 부담이 줄었는가?
캐시와 물질화뷰 hit rate가 실제 운영에서 유지되는가?
P95/P99가 서비스 SLA에 맞는가?
기존 Snowflake/Databricks/Trino 비용 중 어느 부분을 얼마나 줄이는가?

주의점

StarRocks의 시장점유율은 공개 자료만으로 검증되지 않는다. 매출, ARR, 고객 수, 클라우드 사용량이 공개되어 있지 않다.
DB-Engines는 인기도 지표다. 매출이나 설치 수로 해석하면 안 된다.
Ramp 같은 도입률 데이터는 특정 고객·거래 기반 표본이다. 전체 시장 매출 점유율과 다르다.
성능은 partition/bucket 설계, statistics freshness, join cardinality, MV rewrite hit rate, cache warmness, compaction, concurrency limit, hardware/network에 크게 좌우된다.
벤더 벤치마크는 제품이 강한 조건을 보여줄 가능성이 크다. 독립 POC가 필요하다.
Lakehouse 경쟁은 치열하다. Databricks, Snowflake, BigQuery, Trino, Spark, ClickHouse, Dremio, DuckDB 모두 Iceberg/open table format 영역을 강화하고 있다.

검증이 필요한 주장

“StarRocks가 전체 DBMS 또는 클라우드 DW 매출 기준 1% 미만일 가능성이 높다”는 공개 지표 기반 추정이다. 관측된 시장점유율이 아니다.
DB-Engines 2026년 7월 순위와 점수는 월별로 바뀐다. 이후 인용 시점에 다시 확인해야 한다.
Snowflake, Databricks, ClickHouse의 매출/run-rate 수치는 회사 발표 기준이다. 회계 기준, run-rate 산정 방식, 제품 범위가 서로 다를 수 있다.
StarRocks 공식 TPC-H와 Shopee 사례는 실제 워크로드 대표성을 보장하지 않는다. 도입 전 자체 쿼리 세트로 POC해야 한다.
StarRocks의 AI agent workload 전망은 제품 방향과 시장 흐름에 대한 해석이다. 실제 수요 증가는 조직별 analytics 패턴과 agent 도입 속도에 달려 있다.

Source Fidelity Notes

Preserved key numbers: 2024년 전 세계 DBMS 시장 1,197억 달러, 클라우드 DBMS 64%, 2026년 DBMS 시장 전망 1,610억 달러, Snowflake FY2026 Q4 매출 12.8억 달러와 제품 매출 12.3억 달러, 100만 달러 이상 TTM 제품 매출 고객 733곳, Databricks 48억/54억 달러 run-rate, Databricks 데이터웨어하우징 10억 달러 이상 run-rate, ClickHouse 2.5억 달러 ARR, DB-Engines 2026년 7월 주요 순위와 점수, StarRocks 143위/1.61점, StarRocks community 5,000명 이상·GitHub stars 11,000개 이상·contributors 500명 이상, TPC-H 100GB 21초/92초/187초, Shopee 3~10배 성능 개선과 60% CPU 절감, Toss 분당 1,500건 service request.
Preserved frameworks / models: OLAP 시장 5세그먼트, 매출·도입률·인지도·커뮤니티·고객 사례 분리 프레임, StarRocks 성능 레이어 분석, 경쟁 제품군 비교, POC 판단 프레임워크.
Preserved templates / checklists: StarRocks 적합도 표, 경쟁 구도 표, POC 체크리스트, 검증이 필요한 주장 목록.
Omitted or compressed: 원문의 반복 설명, 일부 벤더 메시지성 표현, 긴 출처 설명, 세부 문장 중 공개 페이지에서 재사용 가치가 낮은 보조 문장을 압축했다. 원문 전체는 sources/ layer에 보존했다.
Omission risk: 일부 벤더별 세부 로드맵과 문서 설명을 줄였기 때문에 특정 기능의 버전별 지원 여부를 구현 판단에 바로 쓰기에는 부족하다. 실제 도입 전에는 공식 문서와 릴리스 노트를 다시 확인해야 한다.