Hi Team,

We would like to bring to your attention a precision-related variance observed during data migration from our legacy platform into db Delta tables.

In the legacy system, several numeric columns are defined using the FLOAT data type. During ingestion into the data lake, these values are written to Parquet format and interpreted as DOUBLE precision. The same DOUBLE representation is then used when loading the data into Delta tables.

While there is no data loss at the row level, we are noticing very small differences in decimal precision after the conversion from FLOAT (legacy) to DOUBLE (Data bricks). These differences are typically at the far decimal places but become noticeable during aggregations such as SUM, where the final result differs slightly from the totals calculated in the legacy platform.

Our understanding is that this behaviour is related to IEEE 754 floating-point representation differences and how intermediate rounding is handled across systems during format conversion and aggregation. Since FLOAT and DOUBLE are both approximate numeric types, slight binary representation changes during the migration path (Legacy FLOAT → Parquet DOUBLE → Delta DOUBLE) appear to be introducing this minor variance.

We would appreciate your guidance on the following:

• Recommended best practices to minimise precision drift when ingesting FLOAT data into Delta
• Whether explicit casting to DECIMAL during ingestion would be advisable for such columns
• Any Data bricks-specific configuration or optimisation that can help maintain consistent aggregation results

Please note that record counts and row-level values remain aligned, and this issue only affects aggregated totals at a very small precision level.

Looking forward to your inputs.

Regards,
Divyansh Chouhan