Load a CSV into BigQuery without a script.

When a CSV is the source of truth, for now

A vendor sends you a spreadsheet. A one-off export from another system needs to land in your warehouse. Someone in finance has a file that has to get into BigQuery before Monday's report runs. None of this needs a script, it needs a mapped load you can also repeat if the file shows up again next week.

Before you start

• A CSV or Excel file, and a BigQuery connection already added under Databases.
• Pipelines tier. Data Sync isn't part of Studio.
• Know your write mode ahead of time: a fresh load is usually Insert; a refresh of existing rows is Update or Upsert.

Steps

1. Add the file as a connection: click the + next to Databases and pick CSV/Excel.
2. Open Pipelines → Build and click New Sync.
3. On the left, pick the file connection as your source.
4. On the right, pick your BigQuery connection and the target table, or create one.
5. Drag columns across, or click AI Map to pair them by name.
6. Pick a MODE: Insert for a fresh load, Update or Upsert if rows already exist and you're refreshing them.
7. For Update or Upsert, set a MATCH ON field, an ID or SKU column that's unique per row.
8. Click Dry Run, check the preview, then Save or run it now.

A worked example

A vendor's weekly inventory file needs to land in a staging table, replacing stale rows for SKUs that already exist:

-- target table
CREATE TABLE IF NOT EXISTS `my-gcp-project.staging.vendor_inventory` (
  sku STRING,
  quantity INT64,
  updated_at TIMESTAMP
);

Map the CSV's SKU, Qty and LastUpdated columns to sku, quantity and updated_at, set MODE to Upsert, and MATCH ON to sku. Save it as a job if this file arrives every week, and the same sync just re-runs against the new file.

Check it worked

Dry Run shows you exactly what would write before anything does. After a real run, check row counts in BigQuery against the source file, and look at the job's history for any listed errors, usually a type mismatch between a text column and a numeric target.

Troubleshooting

When to save it as a recurring job instead

If the same vendor sends a fresh file every week at a predictable path, saving the sync as a job and re-pointing the file connection each time beats rebuilding the mapping from scratch. The field mapping stays the same; only the underlying file changes. If the file's structure itself changes column by column, that's a sign to rebuild the mapping rather than trust the old one.

A quick sanity check after loading

Matching row counts between the source file and the target table is the fastest confirmation a load went cleanly:

SELECT COUNT(*) AS row_count
FROM my_gcp_project.staging.vendor_inventory;

If that number doesn't match the CSV's row count minus its header row, check the job history for skipped rows before trusting the table.

When the file changes shape

If a vendor adds or renames a column in a later file, the existing mapping won't automatically pick it up, it will just ignore the new column or fail on a missing one it expected. Treat a structural change in the source file as a reason to revisit the mapping, not something to assume still works.

Reusing the same sync for a different file

If next week's file has the identical column structure, you can point the same file connection at the new file and re-run the existing sync without rebuilding the mapping. It's only a structural change, a renamed or reordered column, that calls for revisiting it.

A note on very large files

For a file in the hundreds of thousands of rows or more, splitting it before loading can be faster than one giant sync, particularly if you're troubleshooting a single bad row somewhere in the middle. A smaller batch that fails is much quicker to debug than one that fails halfway through a much larger load.

Related syncs

See also: Integrations Sync Databricks to BigQuery Load an Excel File into BigQuery..