Yes, there have been documented bugs and specific architectural behaviors in StarRocks that could lead to data being incorrectly deleted, duplicated, or appearing as stale/incorrect when performing DML (Insert/Update/Delete) on Iceberg tables. The most relevant issues reported are: 1. Silent Data Loss: Over-deletion across partitions (#73901) A significant bug was identified where StarRocks' implementation of Equality Deletes could cause "silent data loss." * The Issue: If you have a partitioned Iceberg table and perform a delete using an equality key that does not include the partition column, StarRocks might apply that delete to all partitions instead of just the intended one. * Result: Rows with matching keys in other partitions are incorrectly filtered out (deleted) during reads. This happens because the

IcebergEqualityDeleteRewriteRule

in some versions lacks proper partition scoping. 2. Stale Data due to Data Cache If you update or overwrite an Iceberg table using an external engine (like Spark) and then query it in StarRocks, you might see "incorrect" (old) values if the Data Cache is enabled. * The Cause: StarRocks uses file names and modification times to manage its cache. Since Iceberg files are immutable and the metadata modification time can sometimes be reported as 0, StarRocks may incorrectly treat a new manifest/data file as a cached version of an old one. * Fix/Workaround: Disable the Data Cache (

SET enable_scan_datacache = false;

) or manually run

REFRESH EXTERNAL TABLE <table_name>;

. 3. Duplicate Data Bug (#44753) Users have reported seeing duplicate records in Iceberg v2 tables when using

upsert

or

merge

logic from Spark. This is often related to how StarRocks handles the "Merge-on-Read" (MoR) delete files. If the delete files (position or equality) are not interpreted correctly by the StarRocks scanner, both the original "deleted" row and the new "updated" row may be returned simultaneously. 4. DML Support Limitations It is important to note that

UPDATE

and

MERGE INTO

for Iceberg were historically not supported or were highly experimental in StarRocks. * In older versions, users were forced to use

INSERT OVERWRITE

(which replaces entire partitions) or a manual

DELETE

followed by an

INSERT

. *

DELETE

support for Iceberg was only fully introduced in more recent versions (e.g., v4.1). Using these operations in older versions often required specific configurations and had known edge cases where column mappings could fail if the schema had evolved. 5. NULL values in Equality Deletes (#67321) There were instances where rows deleted using an equality condition on a column containing NULL values were not correctly masked, causing deleted data to reappear in query results. Recommendation If you are experiencing data integrity issues: 1. Check your version: Many of these fixes (especially for over-deletion and NULL handling) are in v3.2.10+, v3.3.3+, and v4.x. 2. Verify the Cache: Try running

SET enable_scan_datacache = false;

to see if the "incorrect" data is actually just a stale cache. 3. Inspect Metadata: Use the metadata tables to see if the delete files exist:

sql
    SELECT * FROM <catalog>.<db>.<table>$files WHERE content != 'DATA';

4. Community Support: For specific "wrong value" bugs where columns seem swapped or values are mutated, these are often linked to Schema Evolution mismatches. Ensure your StarRocks catalog is fully refreshed. References • data_source/feature-support-data-lake-analytics.md • data_source/catalog/iceberg/DML.md • data_source/catalog/iceberg/iceberg_catalog.md

• data_source/catalog/iceberg/iceberg_meta_table.md • data_source/datalake_faq.md • data_source/catalog/iceberg/DDL.md