@Rocky I often read "JSON real-time ingest", "Stream / Routine Load" and "Primary Key Table" are core solutions for challenges faced by legacy data platform, for example Oracle Exadata. Share with me what do you think.

These three features represent a fundamental shift from the "batch-oriented" architecture of legacy platforms like Oracle Exadata to a "real-time" cloud-native model. Here is how they address specific challenges: 1. Primary Key Table: Solving the "CDC/Update" Challenge Legacy systems often struggle to handle high-frequency updates (UPSERTs) in analytical workloads. In a typical Oracle environment, updating millions of rows in a large table can cause massive lock contention or require resource-heavy batch jobs. * The Solution: StarRocks’ Primary Key table uses a Delete+Insert strategy (and Merge-on-Write since v3.x) with a Persistent Index. * The Benefit: It allows you to synchronize real-time Change Data Capture (CDC) from OLTP databases (like Oracle) directly into StarRocks. You get sub-second query performance on frequently changing data without the "Merge-on-Read" overhead that slows down other OLAP systems. 2. Stream / Routine Load: Eliminating "ETL Latency" In legacy platforms, data often moves through complex ETL pipelines (Informatica, DataStage, etc.), leading to "T+1" data freshness (data is at least a day old). * The Solution: Routine Load allows StarRocks to consume directly from Kafka (or other streams) natively. Stream Load provides a high-concurrency HTTP interface for real-time ingestion. * The Benefit: It removes the need for an external ETL middleman. You can go from a transaction in your app to a queryable record in StarRocks in milliseconds, rather than hours. 3. JSON Real-time Ingest: Overcoming "Schema Rigidity" Legacy databases are strictly relational. Handling semi-structured JSON data usually requires pre-parsing it into rigid columns or using expensive XML/JSON clob types that are slow to query. * The Solution: StarRocks supports native JSON data types and Flat JSON. It can automatically detect and extract common fields from JSON data and store them in a columnar format during ingestion. * The Benefit: You get the flexibility of a NoSQL-like schema with the performance of a columnar SQL database. You can ingest raw JSON streams from Kafka and query them immediately using standard SQL without manually redefining your table schema for every new field. Comparison Summary Feature | Legacy Challenge (e.g., Exadata) | StarRocks Core Solution Data Freshness | Batch ETL (T+1 latency) | Routine Load (Sub-second latency) Updates/CDC | Heavy locking / Full-table merges | Primary Key Table (Real-time UPSERTs) Data Variety | Rigid schemas / Slow JSON | Native JSON & Flat JSON (Schema flexibility) Cost/Scale | Proprietary hardware / Vertical scaling | Shared-data/Cloud-native (Horizontal scaling) By combining these, you transform the data platform from a passive "historical archive" into an active "operational engine" that reflects your business state as it happens. References • loading/Json_loading.md • loading/RoutineLoad.md • sql-reference/sql-statements/loading_unloading/routine_load/CREATE_ROUTINE_LOAD.md • using_starrocks/Flat_json.md

@Rocky Regarding "*Primary Key Table: Solving the "CDC/Update" Challenge", will the source data has to be first loaded onto Oracle because you mentioned StarRocks* synchronize real-time Change Data Capture from OLPT system? If the source data has to be loaded first on OLTP system, the bottleneck / lock contention will still happen. The data freshness is still dependent on OLTP system having the CDC ..

That is a very insightful observation. You are correct: if the data entry point is still a legacy OLTP system like Oracle, the ingestion bottleneck (locks and contention) remains on that source system. However, the "core solution" offered by StarRocks isn't just about synchronizing Oracle; it’s about re-architecting the data flow to remove the legacy system from the critical path of high-volume data. Here is how these three features actually solve the bottleneck you described: 1. Bypassing the OLTP System (Stream & Routine Load) Legacy architectures often forced all data through an OLTP database (like Oracle) because that was the only way to ensure data integrity and query capability. * The Shift: With Routine Load (Kafka) and Stream Load (HTTP), you can send high-volume, real-time data (like clickstreams, IoT events, or logs) directly to StarRocks, bypassing the OLTP system entirely. * Result: The OLTP system stays focused on small, mission-critical transactions (e.g., payments), while the "heavy lifting" of massive data ingestion and analytics is handled by StarRocks. 2. Handling "External" Updates (Primary Key Table) Even if you do use CDC to sync from Oracle, the Primary Key Table solves the bottleneck on the analytical side: * The Problem in Legacy: In systems like Exadata, running complex analytical queries while simultaneously performing massive updates causes severe "lock contention." You often have to choose between fresh data or fast queries. * The StarRocks Solution: StarRocks uses a Delete+Insert strategy with a Persistent Index. It handles the incoming stream of updates in the background without locking the table for readers. You can query the data at high speeds even while millions of rows per second are being updated. 3. Schema Flexibility (JSON Real-time Ingest) In an Oracle-first world, adding a new field to your data requires an

ALTER TABLE

and a schema migration, which can lock large tables for hours. * The Shift: Native JSON and Flat JSON allow you to ingest semi-structured data directly. StarRocks can automatically parse and optimize this JSON into a columnar format on the fly. * Result: This removes the "Schema Rigidity" bottleneck. Developers can iterate on application data without waiting for a DBA to update the Oracle schema and the subsequent ETL pipeline. Summary: Where is the source of truth? * For existing business data: You use CDC (via Flink/SMT) from Oracle. Yes, Oracle is still the source, but StarRocks ensures that your analytical queries don't slow down Oracle and that the data in StarRocks is only milliseconds behind. * For new, high-scale data: You use Stream Load or Routine Load to bypass the OLTP system entirely. This eliminates the "Oracle bottleneck" because the data never touches the legacy system. In short, these features allow StarRocks to act as an Operational Data Warehouse that can either sit beside your Oracle system (offloading the query load) or replace it for high-scale, real-time data streams. References • loading/Loading_intro.md • integrations/loading_tools/SMT.md • table_design/table_types/primary_key_table.md • loading/RoutineLoad.md References • loading/Loading_intro.md • loading/loading_introduction/feature-support-loading-and-unloading.md