Conditional
When you import conditional Alteryx functions into Prophecy, the logic of your formulas stays the same, but the syntax changes, because SQL engines usecase expressions instead of IF/IIF/Switch. Prophecy’s import makes these conversions for you.
When reading or debugging generated SQL, you should recognize the case functions below as the SQL equivalent of Alteryx’s conditional functions.
Conversions
Alteryx provides many specialized conversion functions. SQL engines rely on general-purpose casting, encoding and decoding functions, and numeric conversion functions.- BigQuery provides safer casting via
safe_cast, which returnsnullinstead of failing. - Snowflake provides error-handling conversion functions such as
try_castandtry_to_number, which returnnullwhen conversion fails. - Databricks SQL supports
conv()for base conversions, but BigQuery and Snowflake do not have the same general-purpose base conversion function.
- Databricks SQL
- BigQuery
- Snowflake
DateTime
Alteryx provides many specialized datetime functions. The SQL mapping depends on the target engine. Databricks SQL, BigQuery, and Snowflake all support broad datetime functionality, but they differ in function names, argument order, return types, format patterns, and time zone behavior.- Databricks SQL
- BigQuery
- Snowflake
Math
Alteryx offers a large catalog of dedicated math functions, many of which map directly to Databricks SQL. Most Alteryx functions have 1:1 equivalents, with a few cases (random integers, logs) requiring light SQL expressions to reproduce exact behavior.Bitwise
Alteryx uses named bitwise functions (such asBinaryAnd and BinaryOr), while SQL relies primarily on native operators (&, |, <<, >>) and a small set of helper functions. The mappings are direct, with no semantic differences.
Range and bound functions
Range and bound functions behave similarly across SQL engines, but differences arise in how arrays, ordering, and positional logic are handled.betweenworks directly; syntax just shifts to SQL form.Boundrequires an explicitcasestatement.MaxandMinare direct equivalents.MaxIDXandMinIDXin Alteryx identify the position of a value, but SQL engines typically use sorting or window functions (row_number() over (...)) to achieve the same result.
- Databricks SQL
- BigQuery
- Snowflake
Operators
Specialized
Specialized functions have similar conceptual mappings across SQL engines, but differences arise in indexing, null handling, and how arrays are processed. These differences are especially important when translating positional logic from Alteryx.- Indexing: Alteryx uses zero-based indices. BigQuery and Snowflake arrays are 0-based, while Databricks SQL arrays are 1-based.
- Null handling:
NULL()is a callable function in Alteryx, but a literal in SQL. - TOPNIDX: In Alteryx it finds the position of the top N value; SQL engines typically use sorting and positional access to replicate this behavior.
- Databricks SQL
- BigQuery
- Snowflake
String
Key differences across SQL engines:- Indexing: Databricks SQL arrays are 1-based, while BigQuery and Snowflake arrays are 0-based. Alteryx uses 0-based indexing.
- Case sensitivity: All three engines are case-sensitive by default unless you normalize with functions such as
lower()orupper(). - Regex behavior:
- Databricks: Java regex
- BigQuery: RE2
- Snowflake: POSIX-style regular expressions
- Function coverage: Some Alteryx string functions have no direct equivalent and require workarounds or UDFs.
- Substring & trimming: Similar core functions exist across engines, but syntax and edge-case behavior may differ slightly.
- Databricks SQL
- BigQuery
- Snowflake

