A customer guide to migration timeline, architecture, data consistency, performance, integration impact, and SQL compatibility during Eightfold's migration of the analytics dataware house from Amazon Redshift to StarRocks.

Migration Timeline & Parallel Run

Eightfold does not switch a tenant from Redshift to StarRocks in a single cutover event. Instead, both warehouses run side by side for an extended period, so that the consistency validation and performance validation have a stable, live baseline to check against before your tenant depends on StarRocks alone.

Redshift and StarRocks Run in Parallel

Yes — both systems run in parallel. During this period:

• Your existing Redshift-backed dashboards, scheduled reports, and integrations continue to run unchanged.
• The same ingestion pipeline populates both the Redshift and StarRocks warehouses, so the two stay in sync (see "Ensuring Data Consistency" below).
• Cutover of your tenant's production traffic to StarRocks happens only once tenant-specific consistency and performance validation has passed.
• Nothing about this parallel-run period requires action from your team — it is designed to remove risk from the switch, not add a step for you.

Redshift Decommission Timeline

Redshift will be fully decommissioned by end of March 2027. Until that date, Redshift remains available alongside StarRocks; after that date, StarRocks is the sole analytics datawarehouse for all tenants.

Component	Decommission date
Legacy QuickSight dashboards	December 2026
Redshift warehouse & Admin Console credentials	End of March 2027

Admin Console Access During the Parallel Run

Both Redshift and StarRocks connection credentials are available side by side in the Admin Console through end of March 2027. After that date, only StarRocks credentials will remain in the Admin Console — Redshift credentials and endpoints will be removed at the same time Redshift is decommissioned.

What this means for you: there is no forced cutover date for your own tooling before March 2027 — Redshift access keeps working until then. Any client, script, or BI tool that still points at Redshift should be repointed to StarRocks before that date to avoid a hard stop when Redshift credentials are removed.

ETL SLA

There is no change to your ETL SLA as part of this migration. The pipeline populating StarRocks runs on the same schedule and the same freshness guarantees as the existing Redshift pipeline today — the same batch cadence, the same expected data-latency windows. Teams should not expect data to land in StarRocks any later, or any earlier, than they are used to seeing in Redshift.

StarRocks Architecture

This section gives technical teams a high-level view of how StarRocks is deployed for Eightfold — useful context behind the performance behavior and the storage/ownership model described later in this guide.

Shared-Data Architecture

StarRocks is deployed in shared-data mode, which separates compute from storage. Query processing runs on stateless compute nodes that can scale independently of the data itself; the data is durably persisted in Amazon S3 rather than on local disk attached to the compute nodes.

Because storage is decoupled from compute, compute nodes can be added or removed to meet query demand without moving or re-partitioning any data, and data durability does not depend on the lifecycle of any single compute node.

Control Plane & Data Plane

The StarRocks deployment splits cleanly into a control plane (metadata and query coordination) and a data plane (query execution against your data). CelerData operates both planes as Eightfold's managed-service provider for the compute layer, while the underlying storage stays inside Eightfold's own AWS account (see "Data Storage & Security" below for the full ownership model).

What this means for you: FE nodes (control plane) never hold your data themselves — they hold metadata and query plans. CN nodes (data plane) execute queries but read and write your actual data in S3 buckets that stay inside Eightfold's own AWS account.

Ensuring Data Consistency

Data trust is the top priority of this migration. Eightfold validates consistency between StarRocks and Redshift using two independent, automated processes that run continuously throughout the migration and during the parallel-run period — not a one-time check at cutover.

Daily Consistency Backfiller

Every record written to your Eightfold platform (a new profile, an updated application, a deleted record, and so on) is tracked against a durable, source-of-truth event log. A dedicated job compares this event log against what has actually landed in the analytics warehouse and automatically identifies any record that is missing or out of date in the warehouse copy.

• Runs daily, independently for the Redshift pipeline and the StarRocks pipeline, across every Eightfold region.
• When a gap is found, the affected record is automatically re-published through the same ingestion pipeline used for normal updates — no manual intervention required for routine drift.
• A weekly dry-run audit provides an additional trend view of ingestion health independent of the daily self-healing runs.
• Results are compiled into a daily report reviewed by Eightfold's data platform team, with automatic alerting if the amount of drift for any table exceeds a defined threshold.

StarRocks vs. Legacy Warehouse Validation

In addition to the general ingestion-consistency check above, migration to StarRocks is validated with a dedicated job that directly compares the StarRocks warehouse against the legacy Redshift warehouse, table by table:

• Schema parity — confirms every table and column that exists in Redshift also exists in StarRocks, including nested/JSON columns.
• Row-count parity — compares row counts for every dimension and fact table across multiple rolling time windows (yesterday, last 7 days, last 30 days, and full-year), so both recent and historical data are checked.
• Daily fact-table volumes — checked separately, since fact tables are the highest-volume, continuously streaming tables in the warehouse.

This validation runs daily and produces two reports — a Data Consistency Report and a Schema Consistency Report — reviewed by the data platform team, with metrics tracked over time so any regression is caught immediately.

Automated Backfill & Remediation

When validation surfaces a genuine discrepancy, Eightfold does not reload entire tables to fix it. Instead, the remediation process walks back through the affected time window, identifies the specific records that differ between StarRocks and Redshift, and re-processes only those records through the ingestion pipeline. This targeted approach minimizes both time-to-fix and the risk of introducing new inconsistencies through a broad reload.

What this means for you: consistency checking is continuous and automatic, not a one-time pre-migration exercise. The same validation and remediation processes that operate during migration continue to run after your tenant has fully cut over.

Performance: What to Expect from StarRocks

Why StarRocks

StarRocks is a modern MPP (massively parallel processing), columnar, vectorized SQL engine — architected specifically for the workload pattern Eightfold's analytics products generate: many concurrent, low-latency interactive dashboard queries, alongside larger scheduled/export queries, over continuously streaming data.

• Vectorized execution processes data in batches rather than row-by-row, which is particularly effective for the aggregation- and filter-heavy queries behind Eightfold dashboards and reports.
• Real-time materialized views keep pre-aggregated data continuously up to date as new events stream in, rather than relying on periodic batch refreshes.
• Lower operational overhead — StarRocks does not require the periodic table maintenance (e.g. vacuum/analyze-style operations) that Redshift clusters need to sustain query performance over time.

Continuous Performance Monitoring

Query latency on the StarRocks warehouse is monitored continuously and broken out by workload type, so a slowdown in one area cannot silently mask healthy performance elsewhere:

Workload class	What's tracked
Interactive dashboard queries	P50 / P90 / P95 query latency, tracked continuously
Scheduled & Data Hub export queries	Latency and success/failure rate, tracked separately from interactive traffic
Direct customer-view queries (Talent Lake, custom SQL)	Latency tracked as its own class so heavier ad-hoc analyst queries don't distort dashboard SLAs
Query failures	System-side failures and query-side (user) failures are tracked and alerted on separately

Pre-Cutover Validation for Your Tenant

Before any customer's production traffic is cut over to StarRocks, Eightfold validates performance against that tenant's actual query patterns — dashboards, scheduled reports, and any custom SQL — rather than relying on generic benchmarks alone. A tenant only cuts over once both correctness and performance have been confirmed for its specific workload, and both continue to be monitored after go-live.

What this means for you: performance is workload-specific monitoring and pre-validated per tenant, not a single marketing number.

Impact to Your Integrations

Three customer-facing integration points are affected by the underlying warehouse change. Eightfold's goal in each case is to absorb as much of the migration work as possible on our side, and to hand you the smallest, clearest action item where your involvement is required.

Talent Lake — Action May Be Needed

Talent Lake gives you direct database access to your Eightfold data via JDBC/ODBC. Redshift speaks the PostgreSQL wire protocol; StarRocks speaks the MySQL wire protocol. As part of cutover:

• Your Talent Lake connection endpoint and port will change to the StarRocks endpoint.
• Any client, BI tool, or script connecting via JDBC/ODBC will need a MySQL-compatible driver instead of a PostgreSQL driver.
• If your team writes raw SQL directly against Talent Lake, that SQL needs to follow StarRocks/MySQL syntax rather than Redshift/PostgreSQL syntax — see the SQL differences section below.

Eightfold will provide your updated connection details and driver guidance ahead of your cutover date, so your team can update client configuration in advance. Both Redshift and StarRocks credentials remain available in the Admin Console during the parallel run.

Data Hub — Handled by Eightfold

Data Hub scheduled queries and reports are migrated and validated by Eightfold before your Data Hub workload moves to StarRocks. Every existing scheduled query is translated to StarRocks-compatible SQL and its output is checked for parity against the current Redshift result before the switch — not rewritten manually by your team.

What this means for you: your existing scheduled Data Hub reports continue to run and deliver the same output on the new schedule, without you needing to edit or resubmit them. If you plan to author new scheduled queries going forward, write them in StarRocks/MySQL syntax — see the sample table mapping and query below.

QuickSight Custom Dashboards — Eightfold-Led, Customer-Validated

For customers using QuickSight-based custom dashboards, Eightfold's team rebuilds each dashboard on top of StarRocks and validates it internally first:

The legacy QuickSight dashboard is not removed until you've had the opportunity to validate the StarRocks-backed replacement side by side and confirm it meets your expectations — but that validation window closes by December 2026, at which point the legacy dashboard is retired regardless, so plan your sign-off review before then.

Summary

Integration	What changes	Who does the work
Talent Lake	Endpoint moves to StarRocks; PostgreSQL → MySQL wire protocol and driver	Your team updates client/driver config using details Eightfold provides
Data Hub	Existing scheduled queries migrated to StarRocks SQL	Eightfold migrates & validates before cutover; no action needed for existing reports
QuickSight dashboards	Rebuilt natively on StarRocks, run in parallel, then legacy version retired by Dec 2026	Eightfold rebuilds and validates; you confirm before legacy dashboard is removed

Key SQL Differences: StarRocks vs. Redshift

This section is most relevant to teams who write custom SQL directly against Talent Lake or author new Data Hub scheduled queries. Eightfold-managed views, dashboards, and existing scheduled reports are translated and validated by Eightfold — you do not need to rewrite those yourself.

Date & Time Functions

Operation	Redshift	StarRocks
Extract a date part	DATEPART(month, col)	EXTRACT(MONTH FROM col)
Add an interval to a date	date_col + 30	DATE_ADD(date_col, INTERVAL 30 DAY)
Difference between two dates	date_a - date_b	DATEDIFF(date_a, date_b)
Difference in a specific unit (e.g. seconds)	EXTRACT(EPOCH FROM ts_a - ts_b)	TIMESTAMPDIFF(SECOND, ts_b, ts_a)
Interval literal	CAST('30 days' AS INTERVAL)	INTERVAL 30 DAY

JSON Extraction

Operation	Redshift	StarRocks
Extract a JSON field	json_col.field (SUPER dot notation) or JSON_EXTRACT_PATH_TEXT(col,'field')	json_col -> '$.field'
Extract an array element	JSON_EXTRACT_ARRAY_ELEMENT_TEXT(JSON_SERIALIZE(col), n)	CAST(col -> '$[n]' AS VARCHAR)
Nested path access	Chained dot/bracket notation	A single JSON path expression — StarRocks does not support chaining multiple -> operators; nested paths must be expressed as one path string
Using a JSON value in a join or aggregate	Used directly	Must be explicitly cast, e.g. CAST(col -> '$.field' AS VARCHAR) — StarRocks does not allow raw JSON values inside join conditions or aggregate functions
Array length	GET_ARRAY_LENGTH(col)	json_length(col)

Percentile & Statistical Functions

Operation	Redshift	StarRocks
Exact percentile (continuous)	PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY col)	percentile_cont(col, 0.9)
Exact percentile (discrete)	PERCENTILE_DISC(0.9) WITHIN GROUP (ORDER BY col)	percentile_disc(col, 0.9)
Approximate percentile (large datasets)	APPROXIMATE PERCENTILE_DISC(0.9) WITHIN GROUP (ORDER BY col)	percentile_approx(col, 0.9)

Note the syntax shape itself changes, not just the function name: Redshift's WITHIN GROUP (ORDER BY ...) clause has no StarRocks equivalent — StarRocks takes the column and the target percentile as ordinary positional arguments.

Other Notable Differences

Operation	Redshift	StarRocks
Concatenate rows into a delimited string	LISTAGG(col, ',') WITHIN GROUP (ORDER BY col2)	GROUP_CONCAT(col ORDER BY col2 SEPARATOR ',')
Capitalize each word	INITCAP(col)	No direct equivalent — expressed as a combination of UPPER / LOWER
Boolean literal comparison	flag IS TRUE	flag = 1
String concatenation, FULL OUTER JOIN, QUALIFY	Standard syntax	Same syntax — supported in StarRocks without rewriting

What This Means for You

• If you only use Eightfold dashboards & standard reports: No action needed. All SQL behind Eightfold-managed views and existing scheduled reports is translated and validated by Eightfold as part of migration.
• If your team writes custom SQL (Talent Lake / new Data Hub queries): Use this section as a reference when authoring or porting queries. Date arithmetic, JSON extraction, and percentile calculations are the three areas most likely to require a rewrite when moving from Redshift to StarRocks syntax.

Tip: if a query fails after cutover with a syntax error, JSON path-chaining and WITHIN GROUP percentile syntax are the two most common causes. Both have direct, one-line equivalents in the tables above.

Sample Table Mapping & Data Hub Query

Table and schema naming changes as part of the move to StarRocks. The example below uses a sample tenant with group_id = 'efdemo.com':

Warehouse	Sample schema.table
Redshift	efdemo_analytics.efdemo_profile
StarRocks	customer_views.profile

Sample equivalent Data Hub query, same tenant (group_id = 'efdemo.com'):

-- Redshift
SELECT * FROM efdemo_analytics.efdemo_profile;

-- StarRocks
SELECT * FROM customer_views.profile;

Redshift used a per-tenant schema named after the tenant's group_id (e.g. efdemo_analytics for efdemo.com), with tenant-prefixed table names. StarRocks uses a shared customer_views schema with plain entity table names; access is scoped to your tenant's own data. Your Eightfold contact can provide the exact schema/table mapping for your own group_id.

StarRocks SQL Reference

For syntax beyond what is covered in this guide, refer to the official StarRocks SQL reference documentation: https://docs.starrocks.io/docs/sql-reference/

Data Storage & Security

Moving the underlying engine from Redshift to StarRocks does not change who owns or controls your data. This section describes where your data physically resides during and after the migration, and the role Eightfold's managed-service provider plays.

Where Your Data Is Stored

StarRocks separates compute from storage. All warehouse data — every table, materialized view, and partition — is persisted as data files in Amazon S3, in buckets provisioned and controlled within Eightfold's own AWS account and region. This is the same storage model already used elsewhere on the Eightfold platform: your data lives in infrastructure Eightfold owns, not in a third party's environment, and it does not move outside your tenant's existing regional boundary as part of this migration.

CelerData's Role: Managed Service Only

CelerData is engaged strictly as a managed service provider for the StarRocks compute layer — handling cluster provisioning, scaling, patching, and day-to-day operation of the StarRocks software. CelerData does not store a separate copy of your data and does not operate or own the S3 storage layer. The compute nodes it manages read and write directly against the S3 buckets that remain under Eightfold's control; no customer data is copied into CelerData-owned infrastructure.

• Eightfold owns and controls the AWS account and S3 buckets where your data is stored.
• CelerData operates the StarRocks compute service on top of that storage — it does not host an independent copy of your data.
• Separating storage from compute means your data's location and ownership do not change, even though the query engine and its managed operator do.

What this means for you: your data continues to live in Amazon S3, in an AWS account and region controlled by Eightfold — the same ownership model as before this migration. CelerData's role is limited to operating the StarRocks compute software; it is a managed-service operator, not a custodian of your data.

Questions & Support

Your Eightfold Customer Success or Technical Account Manager can share the specific migration timeline, consistency validation results, and performance metrics observed for your tenant. For questions about SQL compatibility on custom queries against Talent Lake or Data Hub, reach out to your Eightfold technical contact and reference this guide.

This document reflects the migration timeline, architecture, data consistency, performance monitoring, integration migration, and data storage processes in place for the Redshift-to-StarRocks datawarehouse migration. Specific timelines and validation results vary by tenant and region; the Redshift decommission date of end of March 2027 applies platform-wide.