Google BigQuery reverse ETL source

Renta reads a data model from your Google BigQuery project and syncs its rows to a business tool through a reverse ETL pipeline.

A data model is a saved query plus the metadata around it: the column list, the unique key that identifies a row between runs, and the descriptions that AI agents read. One model can feed several pipelines.

The connection

A reverse ETL pipeline reads from the same Google BigQuery connection that ETL pipelines use. There is one BigQuery connector, and it appears under both tabs of the catalog.

If your workspace has no BigQuery connection yet, create one first. The service account roles and the project and dataset selection are covered on the Google BigQuery source page.

Create a data model

Models live in Tools > Data models. The list shows how many models exist, which of them AI agents can see, and which are available to reverse ETL.

Click New model to open the wizard.

Define the query

The first step picks the connection and what to read from it.

1. Source.
   The BigQuery connection the model reads from. It is fixed once the model is created.
2. Query type.
   SQL query for a statement you write yourself, or Table or view to sync an existing object as is. The dbt Cloud option is not available yet.

Renta accepts one read-only statement. A query with several statements, or with any write operation anywhere inside it, is rejected when you move on.

Preview the result

Run preview executes the query and shows the first rows together with what the run cost.

The footer reports bytes processed, bytes billed, the estimated cost, whether the cache answered, and the job id, so an expensive model shows its price before anyone builds a pipeline on it.

Choose the scope

The scope decides who may use the model.

A pipeline lists only the models scoped Reverse ETL only or AI agents & Reverse ETL, so a model left on AI agents only never appears in the Data model dropdown.

Confirm the columns and the key

The schema step shows the columns the query returns, with a sample value and a nullability flag for each.

Pick the column that identifies a row between runs in the Unique column. Renta needs it to tell an updated row from a new one, and it verifies the choice when you continue rather than trusting it.

Nulls are checked first, so a column that is both nullable and duplicated reports its nulls and says nothing about the duplicates until you fix them.

Describe the model

Metadata is what a teammate and an AI agent read to understand the model.

1. Model name.
   How pipelines and agent tools refer to the model. Lowercase with underscores.
2. Description.
   What the model represents and when to use it. Markdown is supported.
3. Column descriptions.
   Optional per column. Auto-generate with AI fills them from the query and the sample data.

The right pane previews the tool definition an agent receives, and the token counter shows how much of an agent's context the model consumes.

Save the model

The finished model appears in the list with its scope, row count, and the time of the last update.

You can edit any part later from the Query, Schema & key, Metadata, and Measures tabs.

Use the model in a pipeline

With a model saved, a reverse ETL pipeline connects it to a business tool.

The settings that follow belong to the destination. Each destination page documents its own field mapping and sync options.

What a run leaves in your project

A reverse ETL run works inside your BigQuery project, and it writes there as well as reads.

Every run materialises a plan table describing what to send, and a rejections table holding the rows the destination refused. Renta keeps both tables for the current run and the previous one, then drops what is older. On a first successful sync there are two such tables, and from the second run on there are four.

Reading the model also costs what the query costs, on every run. The preview footer is the cheapest place to find that out.