Skip to main content
Two extract strategies: a watermark query for the initial backfill, and Delta change data feed for everything after it. Unlike the other sources, the runtime can stay inside the workspace.

What you need

  • SELECT on the tables and a SQL warehouse or serverless compute
  • An Octave workspace API key, from Settings → Integrations
  • Nothing outside Databricks — the job runs in the workspace

Where this runs

A Databricks Job is the natural runtime here. It schedules itself, holds secrets, and already has warehouse access, so there is no external function to deploy and no network path to arrange.

The prompt

Copy this into Claude Code, Cursor or any coding agent. It carries the whole flow — reading your warehouse, mapping the columns, posting to Octave, and deploying the result. Fill in section 1 with your real schema and a few sample rows (DESCRIBE TABLE EXTENDED analytics.gtm.opportunities — it also tells you whether change data feed is already on). The more of your actual data it can see, the less it has to guess.
The instruction to show the mapping as a table and wait for confirmation is the part worth keeping. Without it an agent guesses at your column names and buries the guess inside a handler, where a wrong eventType looks exactly like a right one until the data is in.

Hints worth adding

These are the things that go wrong with Databricks specifically. Paste whichever apply into section 1 of the prompt — an agent cannot infer them from a schema. Change data feed is not retroactive. table_changes() returns nothing for history that predates enabling it. The backfill and the incremental run genuinely need two different queries — say so, or you get one that silently misses everything before the switch. CDF emits every update twice. update_preimage and update_postimage both come back. Ask for a filter to insert and update_postimage, or each change maps to two events. DECIMAL loses precision through JSON. Ask for a cast to string and amount sent as a string.