StarRocks and Apache Doris in Production: Real Use Cases and Migration Patterns

A director I worked with a couple of years ago asked me a question I still think about: "if this thing is so much better, why hasn't everyone already moved?" We were three weeks into evaluating StarRocks against a Redshift cluster that was quietly costing more every quarter while getting slower under exactly the queries the business cared about most — customer-facing dashboards, not internal analyst reports. My honest answer at the time was that most teams don't hit the specific pain that makes these engines worth the switch until they're already deep in it: sub-second latency at real concurrency, joins across a schema you don't want to flatten, or an upsert workload a traditional warehouse was never built to serve live. Once you're there, the case tends to make itself. Before you're there, it's premature.

This is the use-case companion to two other pieces on this blog. If you want the architecture — FE/BE, tablets, the data models — read StarRocks & Apache Doris Internals first. If you want the deep mechanics of the CBO, merge-on-write, and materialized view rewrite, that's Inside the StarRocks and Doris Query Engine. This article is neither of those — it's the one I'd hand to someone asking "should we actually adopt one of these, and for what," grounded in real production deployments rather than architecture diagrams. Where I extrapolate beyond a specific published number, I'll say so plainly rather than presenting a guess as a fact.

Why does customer-facing analytics keep pushing teams off traditional warehouses?

Traditional cloud warehouses were built for a different concurrency and latency profile than customer-facing analytics needs — a few dozen analysts running ad hoc queries, tolerant of multi-second response times, is a different design target than hundreds or thousands of end users hitting an embedded dashboard and expecting sub-second response every time. That mismatch is the single most common reason I see teams start evaluating StarRocks or Doris.

Eightfold, an HR-tech company, migrated a workload off Redshift onto StarRocks and reported roughly double the performance at about half the cost. That pairing — faster and cheaper at once — sounds like a sales pitch until you understand the mechanism: a shared-nothing MPP engine with a real cost-based optimizer and fast distributed joins doesn't need the same denormalization discipline a warehouse tuned around scan performance does, so you spend less on both compute (queries finish faster) and pipeline engineering (less ETL work to keep a flat table current). Separately, Eightfold consolidated 49 ClickHouse clusters into a single 45-node StarRocks cluster — a 60% reduction in node count, a 90% reduction in storage footprint, and the elimination of ETL pipelines that existed for one purpose only: pre-joining data into flat tables because the prior engine couldn't join well at query time. That last detail is the part worth sitting with. Those 49 clusters weren't 49 different workloads: a lot of that sprawl was almost certainly denormalization variants of the same underlying data, each cluster holding its own differently-flattened copy because joining live wasn't an option.

The mechanical reason this pattern recurs: an MPP engine that can pick a good join strategy per query — broadcast for a small dimension, shuffle or colocate for two large facts — lets you keep something closer to a normalized schema and join at query time instead of maintaining a denormalization pipeline purely to keep queries fast. That's not a minor convenience. A denormalization pipeline is a second thing that can break, a second copy of the truth that can drift, and a second latency floor (however fast your query engine is, your dashboard is only as fresh as the last ETL run that built the flat table).

There's a second, quieter cost to the denormalize-for-speed pattern that rarely shows up in the initial pitch for a flat table but always shows up eventually: schema evolution. A flat table baked around today's dashboard requirements has to be rebuilt, or grown wide with new columns and backfilled, every time a new metric or dimension gets requested. On a normalized schema with fast query-time joins, adding a new dimension table or a new column to an existing one is a much smaller operation — you're not touching the shape of every downstream flat table that depended on the old structure. Teams that have lived with a flatten-for-speed warehouse for a few years tend to describe this as the thing that actually wore them down, more than the raw query latency — every new ask from the business became a schema migration project instead of a join.

What does it mean to query a lakehouse directly instead of copying data in first?

A newer and, I'd argue, more architecturally interesting pattern is using StarRocks or Doris as a fast SQL layer directly over an open table format — Iceberg most commonly — rather than ingesting data into the engine's own storage first. Coinbase and Pinterest have both adopted StarRocks specifically for this: querying data where it already lives on Iceberg, with StarRocks' vectorized, CBO-driven engine providing the fast scans and distributed joins, instead of running a separate ETL step to copy data into a proprietary storage format before it's queryable.

The mechanical case for this is straightforward once you see it: the traditional trade-off was "fast proprietary storage, slow open storage" — you got speed by giving up format openness, copying data into a warehouse's internal format because that's what made joins and scans fast. Pairing an MPP query engine's optimizer and vectorized execution with an open table format breaks that trade-off. Iceberg (or Hudi, or Delta) gives you format neutrality — any engine can read the data, no vendor lock-in on storage — and StarRocks' external catalog support gives you the fast, join-capable query layer on top, without an ingestion step standing between new data landing in the lake and it being queryable. If you're already invested in an open-table-format lakehouse — see Open Table Formats and Iceberg Internals if you haven't settled on one yet — this is the pattern that lets you add a genuinely fast query layer without duplicating your data into a second storage system.

I'll be direct about where I'm extrapolating: Coinbase and Pinterest are the two specific, documented adopters of this pattern I'm confident naming. Several other companies have presented publicly on petabyte-scale, sub-second StarRocks and Doris deployments more generally — this is a well-established, recurring pattern in the ecosystem at this point, not a one-off — but I'm not going to invent specific numbers for companies beyond the ones I can actually verify.

Worth naming explicitly what this pattern is not: it's not a replacement for a proper lakehouse table format's own transaction guarantees, and it's not free of operational cost. You still need Iceberg (or whichever format you've standardized on) doing the actual job of tracking table state, schema evolution, and snapshot isolation — StarRocks or Doris sitting on top via an external catalog is a query accelerator, not a storage layer replacement. What you gain is a genuinely fast, join-capable SQL surface over data that stays in an open, portable format the whole time, which matters a lot if avoiding vendor lock-in on storage is a real constraint for your organization and not just a nice-to-have. Where this pattern is weakest, in my experience, is very high-cardinality point lookups against the lake directly — object storage latency is what it is, and no query engine sitting on top erases that; the pattern shines hardest on scan-and-join-heavy analytical queries, less so on the kind of single-row lookup a Primary Key table handles natively.

What does sizing for a seasonal load spike actually require?

SF Technology, a logistics company, runs queries against flat tables with roughly 2,000 columns per row at 80,000 transactions per second — an operational analytics workload, not a BI-dashboard workload. The detail I find most instructive isn't the column count or the TPS figure in isolation; it's that they explicitly used StarRocks' high-availability and autoscaling characteristics to handle load during a Double 11-equivalent shopping-festival spike.

That's a genuinely different sizing problem than most analytics platforms are built around. Most warehouse capacity planning targets a steady-state average with some headroom. Sizing for a known, predictable, extreme seasonal peak — where the peak is 5-10x steady state and lasts hours, not the whole quarter — is a different exercise: you either provision for the peak year-round (expensive, wasteful the other 360 days) or you need an engine and operational model that can genuinely scale elastically for the peak window and scale back down afterward. The value StarRocks provided here wasn't "fast queries" in the abstract; it was "fast queries that keep being fast when load jumps 10x for six hours, without a war room."

If your workload has a real seasonal or event-driven spike — retail around a sale event, logistics around a peak shipping period, ad tech around a launch — the operational question to ask a candidate engine isn't just "what's the steady-state benchmark," it's "how does this behave, and how quickly can it rebalance, when load jumps an order of magnitude without warning."

The 2,000-columns-per-row detail is also worth unpacking rather than skimming past. Extremely wide flat tables are a deliberate trade in this use case, not an accident — when the query pattern is dominated by point lookups and narrow filters against an operational table rather than exploratory analytical joins, a wide table with everything an application might need in one row avoids join cost on the hot path entirely, at the cost of storage efficiency and schema flexibility. That's a legitimate design choice for a specific access pattern, and it's a different pattern from the star-schema-with-fast-joins story in the previous section. Recognizing which of the two shapes your actual query pattern is closer to — mostly wide point lookups versus mostly multi-table analytical joins — should drive whether you model closer to SF Technology's wide-table approach or Eightfold's normalized-schema-with-joins approach; they're both legitimate uses of the same underlying engine family, aimed at different query shapes.

What makes real-time CDC-driven tables different from a batch-refreshed warehouse table?

VBill Payment, a fintech company, scaled from 3 billion to 30 billion records while holding millisecond response times, with query response time improving 3x along the way — P95 under 1 second, P98 under 3 seconds — and historical multidimensional analysis that used to take hours dropped to minutes, roughly a 10x improvement. That's not a story about a bigger cluster; a 10x growth in data volume with response times getting better, not worse, is a story about the write path, not the hardware.

This is exactly the use case the primary-key/unique-key upsert model exists for. A fintech ledger or payment-status table isn't append-only — a transaction's status changes as it moves through pending, authorized, settled, and possibly disputed states, and you need the current state queryable within milliseconds of the change, not after a nightly batch job catches up. A traditional warehouse handles this by either running expensive `MERGE` statements on a schedule (batch latency) or by never truly updating and instead layering "latest version" logic into every query (query-time cost that scales with data volume, which is exactly why a naive approach degrades as you scale from 3 billion rows to 30 billion). StarRocks' Primary Key model and Doris's merge-on-write Unique Key model resolve upserts at write time via a primary-key index, so growing data volume doesn't translate into growing query-time merge cost — it's a mechanism, not a benchmark trick, and I go into exactly how it works at the byte level (the per-segment index, the delete bitmap, the sequence-column resolution for out-of-order events) in Inside the StarRocks and Doris Query Engine. If you're evaluating this use case, that's the piece that answers "how," not just "that it works."

What should an actual proof-of-concept test, beyond a speed benchmark?

Most evaluations I've seen default to running the same handful of representative queries against the candidate engine and the incumbent, timing both, and calling it a POC. That tells you something, but it's the least useful part of the evaluation, because query latency on a clean, freshly loaded table under no concurrent load is close to a best-case number every engine can hit. The parts of a POC that actually predict production behavior and that I push teams to include:

• Concurrency, not just latency. Run your representative queries at the concurrency level your actual dashboard traffic produces, not one query at a time. This is precisely where StarRocks and Doris's design advantage over a scan-optimized single-purpose columnar store shows up, and it's the number a single-query benchmark hides completely.
• The write path under real load, not a one-time bulk load. If your use case involves CDC upserts, run the actual sustained upsert rate you expect for at least a few hours, and watch compaction score and disk usage over that window, not just query latency at the start. A short POC window can look great and still hide a compaction-falls-behind problem that only shows up after days of sustained churn.
• A schema change mid-POC. Add a column, add a new dimension table, change a bucketing key on a test table — the operational friction of routine schema evolution is a real cost that a one-time query benchmark never surfaces, and it's exactly the kind of thing that erodes goodwill three months into a production rollout if nobody checked it up front.
• Your worst query, not your best one. Every vendor comparison gravitates toward the query that makes the new engine look best. Deliberately include the query your current engine struggles with most — the multi-way join nobody wants to run during business hours, the report that already needs a materialized rollup to finish in time — because that's the query that actually motivated the evaluation in the first place.

When is migrating off Redshift, BigQuery, Snowflake, ClickHouse, or Druid actually justified?

Here's my honest framework, having sat through a few of these evaluations and one full migration. Migrate when you can point at a specific, currently-painful symptom that maps to one of the four use cases above — not because a case study impressed you at a conference. "We eliminated a denormalization pipeline and doubled performance at half the cost" is a fantastic outcome, but it followed from Eightfold having a specific, expensive problem first. If your current warehouse serves your actual workload adequately, a faster benchmark on someone else's data isn't a reason to migrate.

The trade-offs that are real, and that I've seen teams underweight:

• Operational maturity gap. Redshift, BigQuery, and Snowflake have a decade-plus of operational tooling, documented failure modes, and institutional knowledge in most data teams. StarRocks and Doris are younger — genuinely capable, but you will hit rougher edges in observability, upgrade paths, and community-documented gotchas than you would with an incumbent. Budget for that learning curve honestly, not optimistically.
• Talent and hiring pool. You can hire a Snowflake or BigQuery administrator without much searching. StarRocks/Doris expertise is a smaller, more concentrated pool — you'll likely be growing that skill in-house rather than hiring it fully formed, at least for now.
• The migration itself is real work regardless of the destination's speed. Schema redesign around bucketing and colocation groups, rebuilding ingestion pipelines, requalifying every downstream BI tool and query — none of that shrinks because the target engine is faster. A migration that saves you money in year two can still be a net-negative project in year one if you don't plan for that cost honestly.
• The payoff, when the use case actually matches, is not subtle. Eightfold's numbers, VBill's numbers — these aren't marginal improvements you'd need a statistician to detect. When the workload genuinely matches (customer-facing concurrency, CDC-driven upserts, lakehouse-native serving, seasonal-spike elasticity), the gain is large enough to justify real migration cost.

There's a fifth trade-off worth naming that gets less attention than the first four because it's less visible up front: vendor and support model differences. Snowflake, BigQuery, and Redshift are fully managed services where the platform vendor owns operational responsibility for availability, upgrades, and a large chunk of performance tuning. StarRocks and Doris are open-source engines you either self-operate or run through a commercial distribution (CelerData for StarRocks; several vendors offer managed Doris). Self-operating means your team owns capacity planning, upgrade testing, and incident response for the database itself — work that was previously someone else's problem. That's not automatically worse, and plenty of teams prefer owning that surface for the cost and flexibility it buys them, but it's a genuine shift in where operational responsibility sits, and it should be a deliberate choice rather than a surprise six months into running the cluster.

The other angle worth being honest about is total cost of ownership versus sticker-price compute cost. Eightfold's "half the cost" figure is a real, reported outcome, and the mechanical reasons behind it are sound — fewer redundant clusters, less ETL compute, better hardware utilization from vectorized execution. But that number reflects steady-state savings after a migration was already paid for and a team had already built the operational muscle to run the new engine well. The month-one number, accounting for migration engineering time, parallel-running both systems during cutover, and the productivity dip while a team gets comfortable with a new engine's failure modes, looks different — usually worse — before it looks better. Anyone presenting a StarRocks or Doris cost case to a budget owner should show both numbers, not just the steady-state one, or the second number becomes an unpleasant surprise instead of an expected phase of the project.

graph TD
    Q1{"Is there a specific,
currently-painful symptom?"}
    Q2{"Does it match one of:
customer-facing latency,
lakehouse-native serving,
seasonal elastic scale,
CDC upsert latency?"}
    Q3{"Can the team absorb
a newer-engine ops
learning curve?"}
    NO1["Don't migrate.
Optimize the current engine instead."]
    NO2["Don't migrate on speed alone.
The case studies won't repeat
for a mismatched workload."]
    NO3["Migrate, but budget real
time for the ops ramp-up
before counting savings."]
    YES["Migrate. The payoff in these
four use cases is large,
not marginal."]
    Q1 -->|"no"| NO1
    Q1 -->|"yes"| Q2
    Q2 -->|"no"| NO2
    Q2 -->|"yes"| Q3
    Q3 -->|"no, not yet"| NO3
    Q3 -->|"yes"| YES
          

My actual opinion, for what it's worth: if you're running customer-facing dashboards on a warehouse that was designed for internal analyst concurrency, or you're maintaining a denormalization ETL layer purely because your current engine can't join well, or you have a CDC-driven table where "eventually consistent within an hour" isn't good enough anymore — migrate, and expect the kind of result Eightfold and VBill Payment reported. If none of those describe you and you're evaluating StarRocks or Doris because a case study was compelling in the abstract, spend a month characterizing your actual pain first. The engines are genuinely good. That's not the same as being the right next move for every team reading a benchmark.

StarRocks or Doris — does the choice between them matter for these use cases?

Less than people expect, and I say that having watched teams spend weeks debating it before running a single query. Both engines share the FE/BE ancestry and both would serve every use case in this article reasonably well — the choice between them tends to come down to factors that are secondary to the use case itself. If lakehouse-native serving over Iceberg is your specific driver, StarRocks has pushed harder and longer on that specific positioning, and the Coinbase/Pinterest precedent is StarRocks-specific. If Apache Software Foundation governance matters to your organization for procurement or compliance reasons, or you value Doris's broader out-of-the-box connector ecosystem, that tilts the other way. For the CDC-upsert and seasonal-elasticity use cases, both engines' underlying mechanisms — merge-on-write, autoscaling BE nodes — are close enough in capability that the deciding factor is usually going to be team familiarity, vendor support availability in your region, or which one your POC happened to run better on for your specific query shapes, not a structural gap between the two. I go deeper on where they genuinely diverge — governance, emphasis, and the convergence caveat that any feature gap named today may be narrower by the time you read this — in StarRocks vs ClickHouse vs Doris.

One more practical note from having sat through a few of these decisions: don't let the StarRocks-versus-Doris debate become a substitute for the harder and more consequential decision, which is whether either of them is the right move at all given your specific workload and team. I've watched evaluation cycles burn a month comparing StarRocks and Doris feature-by-feature for a use case that, on reflection, didn't actually need either — the existing warehouse just needed better query patterns or a materialized view, not a new engine. Settle the "should we move" question with the framework above before spending real time on "which one."

What to carry away

The recurring pattern across every real deployment here is the same: a workload that needed low-latency joins at real concurrency, or write-time upsert resolution, or elastic scaling for a known spike, or a fast query layer over open lake storage — needs that traditional warehouses and single-purpose columnar stores weren't built to meet cheaply. Eightfold's Redshift migration and ClickHouse-cluster consolidation, Coinbase and Pinterest's lakehouse-native serving over Iceberg, SF Technology's seasonal elastic scaling, and VBill Payment's real-time CDC upserts at 10x data growth with flat latency are four distinct shapes of the same underlying story: match the engine's actual mechanical strengths to a workload that needs them, and the payoff is large and measurable, not a marginal benchmark win.

For the architecture underneath all four use cases, read StarRocks & Apache Doris Internals. For exactly how the CBO, merge-on-write, and materialized view rewrite work mechanically — the "how" behind every case study in this article — read Inside the StarRocks and Doris Query Engine. And if ClickHouse is still on your shortlist, StarRocks vs ClickHouse vs Doris puts all three head to head on the dimensions that actually decide a project.