InfluxDB 3.x SQL vs InfluxQL compatibility for migrated queries

InfluxDB 3.x Query Language Transition Challenges

InfluxDB 3.x represents a significant architectural shift from both 1.x and 2.x, moving to a Parquet/Arrow-based storage engine and making SQL (via Flight SQL) and InfluxQL the primary query interfaces while deprecating Flux support. This creates a compatibility boundary for teams migrating from earlier versions where query syntax and semantics may not translate directly.

The 1.x to 2.x transition already introduced breaking changes: InfluxQL was partially maintained through a compatibility layer mapped to buckets via DBRP, but continuous queries and many InfluxQL functions were not supported. Now with 3.x, organizations face a second major transition point where their existing InfluxQL queries may behave differently or require modification.

Key questions remain about which query language to standardize on when upgrading to 3.x, particularly for teams with substantial existing InfluxQL codebases. The documentation indicates SQL and InfluxQL are primary in 3.x, but the extent of functional parity with 2.x Flux queries is unclear.

Which specific InfluxQL features and functions have known behavioral differences or limitations when executed against InfluxDB 3.x compared to 2.x, particularly regarding time series functions, continuous queries, and the DBRP mapping layer?

How can teams systematically identify and remediate queries that will fail or produce different results when migrating from InfluxDB 2.x Flux queries directly to InfluxDB 3.x SQL or InfluxQL interfaces?

What migration tooling or validation frameworks exist to compare query results across the 1.x → 2.x → 3.x transition to ensure data integrity and query correctness?