Skip to main content
While importing Alteryx workflows to Prophecy pipelines, Prophecy converts Alteryx functions into equivalent SQL functions. The SQL dialect used in imported pipelines is determined by the target platform you select during import (Databricks, BigQuery, or Snowflake). The following tables list all the Alteryx functions that Prophecy supports and their corresponding SQL functions. If a table does not specify Databricks, BigQuery, or Snowflake, functionality is equivalent for all three dialects.

Conditional

When you import conditional Alteryx functions into Prophecy, the logic of your formulas stays the same, but the syntax changes, because SQL engines use case 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 returns null instead of failing.
  • Snowflake provides error-handling conversion functions such as try_cast and try_to_number, which return null when conversion fails.
  • Databricks SQL supports conv() for base conversions, but BigQuery and Snowflake do not have the same general-purpose base conversion function.

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.

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 as BinaryAnd 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.
  • between works directly; syntax just shifts to SQL form.
  • Bound requires an explicit case statement.
  • Max and Min are direct equivalents.
  • MaxIDX and MinIDX in Alteryx identify the position of a value, but SQL engines typically use sorting or window functions (row_number() over (...)) to achieve the same result.

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.

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() or upper().
  • 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.