Computed Table vs Computed File

You reached this page from the Computed Tables sub-tree. If you already know you want a warehouse-backed derived table, keep reading; if the raw data lives in files on object storage, jump to Computed File vs Computed Table instead.

When a Computed Table fits

A Computed Table is the right choice when:

• The source data lives in a JDBC warehouse (Snowflake, PostgreSQL, Redshift, SQL Server, Oracle, BigQuery, Databricks, and similar).
• You want to reuse the warehouse's own SQL dialect and its query planner (index-aware, statistics-aware, cost-based).
• The transformation needs joins across multiple base tables or views in the same datastore.
• You want the query to run inside the warehouse itself, not pull data into a separate engine.
• You do not need Qualytics to profile the source container before you build the Computed Table.

When a Computed File fits instead

Switch to a Computed File if:

• The source data lives in files on object storage (Amazon S3, Google Cloud Storage, Azure Data Lake Storage).
• The files are Parquet, ORC, Avro, CSV, TSV, PSV, JSON, Excel, Delta, or Iceberg.
• You want to normalize columns, cast types, or flatten nested arrays (via lateral views + EXPLODE) using Spark SQL.
• You are OK with a single-source restriction (one source_container_id per Computed File, no joins inside the container itself).

Side-by-side comparison