@Rocky Hi, I have a question about the atomicity guarantees of INSERT OVERWRITE. [Context] • StarRocks version: 3.5 • Primary Key model table • The table is created WITHOUT a PARTITION BY clause (unpartitioned) • Plan: use INSERT OVERWRITE to fully replace the table's contents • Goal: atomic refresh with NO downtime window where readers see empty results [What the docs say] • Temporary Partition doc: "atomically overwrite data in a partition" / "atomically replace the original formal partition with the temporary partition" • INSERT doc: "Creates temporary partitions ... Swaps the original partitions with the temporary partitions" • Data Distribution doc: when PARTITION BY is omitted, "the entire table is considered a partition" Combining these three, I'd infer that an unpartitioned table has a single implicit partition and INSERT OVERWRITE performs the same temp-partition-swap on it atomically. However, I could not find any doc section that explicitly states this guarantee for unpartitioned tables. [Questions] 1. Does INSERT OVERWRITE on an unpartitioned Primary Key table actually go through the temp-partition-swap mechanism? 2. If so, is the swap still atomic, i.e. do concurrent readers continue to see the old data until the swap point and then instantly see the new data (no empty-result window)? 3. Are there any minimum StarRocks version requirements for this behavior? Any pointers to docs, source code, or release notes would be greatly appreciated. Thanks!

The atomicity guarantees of

INSERT OVERWRITE

in StarRocks, particularly for unpartitioned Primary Key tables, are a common point of interest for building robust data pipelines. Based on the documentation and the internal architecture of StarRocks 3.5, here are the answers to your specific questions: 1. Does it use the temp-partition-swap mechanism? Yes. Even if a table is created without a

PARTITION BY

clause (unpartitioned), StarRocks treats the entire table as a single implicit partition. When you execute

INSERT OVERWRITE

, the system follows these internal steps: 1. Creation: It creates a temporary partition (internal) that mirrors the single implicit partition of your table. 2. Loading: The new data is loaded into this temporary partition. 3. Swap: Once the load is successful, StarRocks performs an atomic swap between the original partition and the temporary partition. 4. Cleanup: The old partition is marked for deletion. 2. Is the swap still atomic (No downtime)? Yes. The swap is an atomic metadata operation performed by the FE (Frontend) Leader. * Concurrent Readers: Readers will continue to see the "old" data during the entire loading phase. * The Switch: At the exact moment of the commit (the swap), the metadata is updated. Subsequent queries will immediately see the new data. * No Empty-Result Window: Because the swap happens only after the data is fully written to the temporary partition and committed, there is no period where the table appears empty or contains partial results. 3. Minimum StarRocks version requirements? * INSERT OVERWRITE Support: This feature was introduced in v2.4. * Primary Key Model Support: Full support for

INSERT OVERWRITE

on Primary Key tables was solidified in the v2.5/3.0 era. * StarRocks 3.5: In your version (3.5), this is the standard and recommended way to perform a full-table refresh with atomicity. Important Notes for Primary Key Tables: * Memory/Resource Usage: Since the Primary Key model uses a "Delete+Insert" strategy internally,

INSERT OVERWRITE

is often more efficient for full refreshes than deleting all rows and then inserting, as the swap mechanism avoids the overhead of managing millions of individual delete markers for the old data. * Transactional Context: Note that as of v3.5,

INSERT OVERWRITE

is not supported within an explicit

START TRANSACTION ... COMMIT

block (it is considered a standalone transaction). * Alternative (SWAP WITH): While

INSERT OVERWRITE

is the most common approach, some users use

ALTER TABLE table_a SWAP WITH table_b

. This is also atomic but requires you to manage the temporary table yourself.

INSERT OVERWRITE

is generally preferred as it automates the temporary partition management. In summary: Your inference is correct. Your plan to use

INSERT OVERWRITE

on an unpartitioned Primary Key table will provide the atomic, no-downtime refresh you are looking for. References • faq/Others.md • loading/InsertInto.md • sql-reference/sql-statements/loading_unloading/INSERT.md • table_design/data_distribution/Temporary_partition.md