Databricks n8n integrationAutomate Databricks with n8n.

Runs SQL on a warehouse and waits for the result, so the next node receives rows rather than a job reference.

• Warehouse: the SQL warehouse that executes the statement, chosen from the list or given by its ID.
• Query: the statement itself, along the lines of SELECT * FROM my_table LIMIT 10.
• Query Parameters: named values you reference in the SQL as :name, so a workflow sends WHERE ID = :user_id instead of gluing a value into the string.

Adds a folder inside a volume, which is what a workflow does before writing files into a path that does not exist yet.

• Volume Path: the volume in the format catalog.schema.volume.
• Directory Path: where the folder goes inside that volume, nested like folder1/subfolder, with no leading slash.

Removes a folder from a volume, the cleanup half of an export routine that would otherwise pile up folders forever.

• Volume Path: the volume that holds the folder, written catalog.schema.volume.
• Directory Path: the folder to remove, relative to the volume root and without a leading slash.

Deletes a single file from a volume. The file is addressed by its path, not by an identifier, so the workflow has to know where it put it.

• Volume Path: the target volume, in the format catalog.schema.volume.
• File Path: the file inside that volume, such as folder/file.txt, again with no leading slash.

Pulls the content of a file out of a volume and hands it to the workflow as binary data, ready to attach, forward or parse.

• Volume Path: the volume to read from, in the format catalog.schema.volume.
• File Path: the file to fetch, for example folder/file.txt, without a leading slash.

Reads the metadata Databricks holds about a file, without moving its content. That keeps a check cheap when a workflow only needs to know whether the file exists yet.

• Volume Path: the volume to inspect, written catalog.schema.volume.
• File Path: the file to look up, such as folder/file.txt, with no leading slash.

Returns what sits inside a volume path, one item per file, which is how a workflow loops over a batch it did not create itself.

• Volume Path: the volume to browse, in the format catalog.schema.volume.
• Directory Path: optional; leave it empty to list the volume root.
• Page Size and Page Token: how many files come back per page, and the token that fetches the next one.

Writes binary data carried by the incoming item into a volume, for files up to 5 GiB.

• Volume Path: the destination volume, in the format catalog.schema.volume.
• File Path: where the file lands inside it, such as folder/file.txt.
• Input Data Field Name: the name of the field on the incoming item that holds the binary data.
• Overwrite: whether an existing file at that path gets replaced.

Sends a follow-up question into a Genie conversation that is already open, so the exchange keeps its context instead of starting over.

• Space ID: the Genie space the conversation belongs to.
• Conversation ID: the thread to continue, usually carried over from an earlier node with an expression such as {{ $json.field }}.
• Message: the question, written the way a colleague would ask it.

Genie answers a question with a SQL attachment; this operation runs that attached statement against the space's warehouse.

• Space ID and Conversation ID: which space and which thread the answer came from.
• Message ID: the answer that carries the attachment.
• Attachment ID: the specific attachment to execute, since one message can hold more than one.

Reads a single message back from a conversation, which is how a workflow checks whether Genie has finished composing its answer.

• Space ID: the Genie space in play.
• Conversation ID: the thread the message belongs to.
• Message ID: the message to read, referenced from an earlier node with an expression like {{ $json.field }}.

Describes a Genie space, so a workflow can confirm it is pointing at the right one before it starts asking questions of it.

• Space ID: the only thing this operation needs, and the same value every other Genie operation expects.

Collects the rows produced by an attachment's SQL execution, which is the step that finally turns a Genie answer into usable data.

• Space ID and Conversation ID: the space and thread being read.
• Message ID: the answer whose query was run.
• Attachment ID: the attachment whose results you want back.

Opens a new thread in a Genie space with a first question in plain language. Everything else in the Genie resource hangs off the conversation this creates.

• Space ID: the space that will answer.
• Initial Message: the opening question, which you can build from an earlier node with an expression such as {{ $json.field }}.

Sends a payload to a model serving endpoint and returns what the model answers. The node fetches the endpoint's OpenAPI schema to work out the right invocation URL and the expected input format.

• Endpoint: the serving endpoint to query, picked from the list or given by name.
• Request Body: the JSON payload, validated against the endpoint schema at runtime, so a malformed body fails fast.

A catalog sits at the top of the Unity Catalog hierarchy, above schemas and tables. This operation registers a new one in the workspace, so later steps have somewhere governed to write.

• Catalog: the catalog to use, picked from the workspace list or typed in as a name.
• Comment: an optional description, and the placeholder suggests Catalog description. Worth filling in when several teams share the same workspace.

Registering a SQL function makes a reusable expression available to everything that queries the schema. The node creates it from the definition passed in.

• Catalog and Schema: where the function lands, both chosen from the workspace lists.
• Function Name: the name it gets, along the lines of my_function.
• Input Parameters: a JSON array where each parameter carries name, type_name and type_text.
• Return Type: what the function gives back, such as STRING, INT or DOUBLE.
• Routine Body: the language of the body. Routine Definition: the body itself, a SQL expression in the style of RETURN x + 1.

Registration here means declaring a storage path as a table. The Create Table API only supports external Delta tables, so the data already lives somewhere when this step runs.

• Catalog, Schema: the pair that scopes the new table.
• Table Name: the registered name, in the style of my_table.
• Storage Location: the external storage root URL, for instance s3://my-bucket/path/to/table.
• Columns, in Additional Fields: a JSON array of column definitions, each with a name and a type_name among STRING, LONG, DOUBLE, BOOLEAN, DATE or TIMESTAMP.

Volumes are the Unity Catalog home for files rather than rows. Declaring one gives file steps a governed destination.

• Catalog, Schema: the parents the volume belongs to.
• Volume Name: the name of the volume, such as my_volume.
• Volume Type: with MANAGED, Databricks manages the storage; with EXTERNAL, the volume points at storage you already own.
• Storage Location, in Additional Fields: the external storage location, required for EXTERNAL volumes.

Taking a catalog out removes the widest container in Unity Catalog, the one that holds the schemas. That makes it the delete worth putting a manual approval step in front of.

• Catalog: the catalog to use, selected in the list or passed as an expression such as {{ $json.field }} when the name comes from an earlier node.

When a SQL function has been superseded, this removes the old definition from its schema so queries stop resolving to it.

• Catalog, Schema: the location the function was registered in.
• Function: the function to access, selected in the resource locator rather than typed as a bare label.

Dropping a table removes its registration from Unity Catalog. The table is identified by its place in the hierarchy, not by a name on its own, so the three fields work together.

• Catalog and Schema: the two levels above the table.
• Table: the table to access, chosen among the tables of that schema.

Volumes that have outlived their purpose come off here. The node wants the volume name, not the storage path sitting behind it.

• Catalog, Schema: the container the volume sits in.
• Volume Name: the name of the volume, for example my_volume.

Catalog information comes back as a single item you can branch on, which is what a workflow needs before it starts writing into that catalog.

• Catalog: the catalog to use. Follow it with an IF node to branch on what the lookup returns.

Before a workflow leans on a SQL function, reading back its registered definition shows what the function expects and what it returns.

• Catalog, Schema: where to look.
• Function: the function to access, resolved through the resource locator.

Table information is what a downstream step reads when it needs the registered details of a table rather than the rows inside it.

• Catalog and Schema: the path down to the table.
• Table: the table to access, picked in the resource locator.

Checking a volume first saves a run that would otherwise fail halfway through an upload. The operation returns that volume's information.

• Catalog, Schema: the two names that scope the lookup.
• Volume Name: the volume itself, such as my_volume.

Every catalog the credential can see comes back in one call, with no field to fill in at all. That makes it the natural opening move when a workflow has to work across a whole workspace instead of one catalog it already knows about.

Functions pile up quietly in a schema. This returns what is registered, and since both filters are optional, an unfiltered call reaches wider than a single schema.

• Catalog: filters by catalog, optional.
• Schema: filters by schema, optional, and it requires a catalog to be set alongside it.

The tables registered in a schema arrive as items, one per table, ready to loop over. Leaving both filters empty widens the call rather than narrowing it.

• Catalog: an optional filter on the catalog.
• Schema: an optional filter on the schema, which only applies once a catalog is chosen.

Storage reviews start with knowing what exists. The operation returns the volumes declared in a schema, so a workflow iterates over them instead of hardcoding names.

• Catalog: optional, restricts the listing to one catalog.
• Schema: optional, and it needs a catalog set next to it.

Catalog metadata drifts as teams change. Updating it touches the catalog's own information and leaves everything inside untouched.

• Catalog: the catalog to use, meaning the one being updated.
• Comment: the optional description, shown with the placeholder Catalog description. It is the piece teams actually keep current.

Index creation is where a vector search setup begins: the index is what queries hit later, and it belongs to an endpoint.

• Index Name and Endpoint Name: the index being created and the vector search endpoint it lives on.
• Primary Key: the primary key column of the index, shown with the placeholder ID.
• Index Type: DELTA_SYNC syncs automatically with a source Delta table, DIRECT_ACCESS supports direct read and write of vectors and metadata.
• Delta Sync Index Spec and Direct Access Index Spec: the JSON specification for each of those two types.

Index details answer the question a workflow asks right before it searches: is this index actually there? One field is all it takes.

• Index Name: the name of the vector search index, typed in or handed over from a previous node with an expression like {{ $json.field }}.

One endpoint can host several indexes. This returns them all, scoped to the endpoint you name, which keeps the result readable even in a busy workspace.

• Endpoint Name: the vector search endpoint whose indexes you want listed.

Semantic search over an index runs from this operation, either from raw text or from embeddings computed upstream.

• Query Type: text has Databricks convert your Query Text into vectors, vector sends the Query Vector you supply.
• Index Name: the index being searched.
• Columns to Return: a comma separated list of column names, like content, url.
• Search Mode: HYBRID mixes semantic and keyword search, ANN stays on pure vector similarity.
• Score Threshold, in Options: a minimum relevance score, between 0 and 1.