Use an External Lakehouse

A project’s tables normally live in the built-in PlaidCloud Lakehouse. Instead, you can point a project at your own Snowflake or Databricks lakehouse as its data backend. Workflows then read and write project tables directly in your warehouse — the data stays in your account, under your governance and billing, while PlaidCloud drives the transformations, workflows, and dashboards over it.

The project’s tables live in your warehouse; PlaidCloud reads and writes them in place rather than copying the data into its own store.

How an External Lakehouse Is Registered

Registering a Snowflake or Databricks lakehouse for your tenant isn’t self-service — a PlaidCloud administrator sets it up on your behalf. Give your PlaidCloud contact the details below for whichever engine you’re connecting. Once it’s registered, the lakehouse becomes available to pick when you create a project.

Snowflake

Field	What to provide
Hostname	Your Snowflake account host.
Superuser	The Snowflake user PlaidCloud authenticates as.
Database	The database PlaidCloud creates and manages project schemas in.
Warehouse	The compute warehouse PlaidCloud runs queries under.
Role	The Snowflake role PlaidCloud acts as.
Private key	The raw, unencrypted PEM private key for key-pair authentication — paste the key text itself, not a base64-encoded copy. Passphrase-protected keys aren’t supported yet.

Generate a key pair and assign the public key to the Snowflake superuser before handing off the private key. The role must be able to create, read, and write tables in the target database.

Databricks

Field	What to provide
Hostname	Your Databricks workspace URL.
HTTP path	The HTTP path of the SQL warehouse PlaidCloud runs queries against.
Unity Catalog	The Unity Catalog catalog PlaidCloud creates and manages project schemas in.
Personal access token	A Databricks PAT for authentication.

The token’s identity must be able to create, read, and write tables in that catalog.

Neither registration asks for a schema — each project gets its own, derived automatically from its DSN when the project binds to the lakehouse.

The registration form has a Test Connection button that opens a live connection with the details entered and reports success or the reason it failed, without saving anything — so credentials can be verified before the lakehouse is registered. A Snowflake test needs the raw, unencrypted PEM private key (a passphrase-protected key is reported as unsupported); a Databricks test uses the PAT.

Bind a Project to the Lakehouse

Once your tenant has at least one external lakehouse registered, the New Project dialog (Analyze > Projects > New Project) offers a lakehouse picker: choose Tenant Default, or pick a specific registered lakehouse. Tenant Default is the built-in PlaidCloud Lakehouse unless an administrator has set a registered external lakehouse as the tenant default (see Set a tenant default below), in which case new projects land there automatically. From then on:

Every table the project’s workflows create, load, or transform is created and written in your lakehouse.
Reads — in steps, views, and dashboards — run as queries against your warehouse.
Nothing is copied into the PlaidCloud Lakehouse; the data stays in your account.

Build workflows exactly as you would on the built-in lakehouse — import, transform, join, and publish steps all work the same way. The backend is set when the project is created and applies to the whole project.

Managing Registered Lakehouses

Set a Tenant Default

An administrator can designate one registered external lakehouse as the tenant default. New projects that pick Tenant Default then bind to it instead of the built-in PlaidCloud Lakehouse. The default is a single tenant-wide setting — there’s no per-project default. Changing it affects only projects created afterward; existing projects keep the backend they were created with.

Deleting a Lakehouse

Deleting a registered lakehouse is refused while any project is still bound to it — the error lists the bound projects. Rebind or delete those projects first, then delete the lakehouse (or force the deletion, which leaves the listed projects pointing at a lakehouse that no longer exists).

Importing Files Into a Lakehouse-Bound Project

Importing a CSV, Parquet, XML, or Access file into a lakehouse-bound project loads it through your warehouse’s own native, parallel bulk-load path: a Snowflake internal stage plus COPY INTO for Snowflake, a Databricks managed volume plus COPY INTO for Databricks — instead of staging the file through an external cloud bucket. There’s no extra cloud IAM to configure, and it works the same way regardless of which cloud your warehouse runs on.

Exporting Query and Table Results

Exporting query or table results from a lakehouse-bound project delivers straight to cloud storage rather than routing every row back through PlaidCloud:

Snowflake — the export runs as a Snowflake server-side unload (COPY INTO a stage), so the warehouse writes the results directly to storage. Large exports are automatically split into multiple files (previously an export above Snowflake’s single-file limit would fail).
Databricks — the export runs as a Databricks server-side unload (INSERT OVERWRITE DIRECTORY into a Unity Catalog managed volume), so the warehouse writes and encodes the results itself and PlaidCloud only relays the finished files to storage. Large exports roll across multiple files automatically, and CSV can be delivered gzip-compressed.

Dashboards Over Lakehouse Data

Dashboards work over both engines.

Databricks — dashboards query the lakehouse through the Databricks driver, the same as any other project.
Snowflake — dashboards authenticate with a key pair and are enabled per tenant. A new project created after your tenant has Snowflake dashboards enabled gets its dashboard automatically. An existing Snowflake-backed project gets its dashboard the next time it’s published.