Tableau Prep to BigQuery conversion reads the .tfl or .tflx graph, maps joins, filters, calculations, aggregations, unions, pivots, and outputs into BigQuery Standard SQL, and keeps the original step structure visible through named CTEs. The result replaces row-level transformation logic; credentials, schedules, and Tableau Server or Cloud orchestration remain separate deployment work.
- Connecting Tableau Prep to BigQuery still leaves the Prep flow in place; generated SQL moves the transformation into the warehouse.
- BigQuery needs its own identifier quoting, date functions, array handling, and unpivot form.
- Output steps tell you where the flow writes, but they don't choose a BigQuery deployment schedule or permission model.
- BigQuery generation is beta and should be checked against representative flow output before replacement.
Connection and conversion solve different problems
Tableau Prep can read from and write to BigQuery. That keeps Prep as the transformation runtime. A migration to warehouse-owned SQL takes the calculations and row operations out of the visual flow so they can run under the team's existing BigQuery scheduling, testing, and review process.
The .tfl or .tflx file carries the useful evidence: source relations, field changes, joins, branch connections, aggregations, and output definitions. Those details provide a safer starting point than rebuilding the query from the final table alone.
Generate BigQuery SQL, not generic SQL
BigQuery uses backticks for identifiers, UNNEST for array work, and functions such as DATE_DIFF, PARSE_DATE, and FORMAT_TIMESTAMP. An unpivot may use an array of STRUCT values instead of PostgreSQL's lateral VALUES pattern. Dialect-aware generation handles those choices before the first warehouse run.
- Use fully qualified project.dataset.table references where the source is known
- Keep field names and aliases stable across CTE boundaries
- Translate null and type behavior with BigQuery functions
- Review Python script steps and connector-specific custom SQL
Keep the visual flow traceable
Named CTEs let a reviewer compare generated SQL with the original Prep steps. A join CTE should name its inputs and condition; a calculated-field CTE should preserve the field name the downstream branch expects. This costs a few extra lines and saves hours when totals differ.
Branches deserve special attention. A flow can reuse one step in several outputs, and flattening that graph into one linear query can duplicate work or lose a filter that applies to only one branch.
Validate before retiring the flow
Run the generated query on representative data and compare row counts, keys, null rates, and important aggregates with the Prep output. Deflows' Parity Test Kit currently covers Tableau Prep to PostgreSQL, so BigQuery output needs the team's own warehouse-side comparison.
Deflows parses the raw flow in the browser and marks BigQuery output as beta. The generated SQL is a review draft; deployment credentials and scheduling stay with your BigQuery environment.
Primary references
Questions teams ask
Is connecting Tableau Prep to BigQuery the same as converting the flow?
No. A BigQuery connection changes where Prep reads or writes data while Tableau Prep still runs the transformations. Conversion moves the transformation logic into BigQuery SQL so the flow can be replaced after validation.
Can Deflows validate the BigQuery result automatically?
The current Parity Test Kit supports Tableau Prep as the source and PostgreSQL as the target. BigQuery SQL needs a warehouse-side comparison of generated results against the existing Prep output.