BUILDING Parts of this page describe what is not built yet, and each says so.
The data plane and what stays in your account
RunningLake has two halves. The control plane is ours: the console, the API, your configuration and your audit log. The data plane is where your queries run and your files live.
What a data plane is
A data plane is a Kubernetes cluster, with its object storage, its keys and its catalog. An environment is bound to one plane, and everything the environment holds is on that plane: its tables’ files and the results of its queries.
Whose account the plane runs in depends on whether you connect a plane or we host one. Your bucket is the one in your own cloud account, where a plane you connect keeps your tables’ files, and registering your own encryption key is built in the console and is not switched on yet. A plane we host is in our account, and the trial is designed to run on a bucket of ours. “Your data never leaves your account” is true of where your tables’ files are stored on a plane in your own account, and we will not write it unqualified.
Even then, “your account” is where your data is stored, not a promise that we have no way into it. The control plane assumes a role in that account, called the provisioner role, which the plane’s setup creates there. It uses it to create and manage keys, including to enable, disable and rewrite the policy of a project’s key and to schedule and cancel its deletion, to read and write the data bucket and to sign links to your storage. Encryption keys says what that means for a revocation. It reaches the account from an identity of its own, with an external identifier that belongs to the plane.
How it talks to us
The cluster dials out and we never dial in: your plane’s agent opens the connection, and
commands go down it. What comes back is mostly identifiers and numbers: rows, bytes, duration,
states. Each field the plane sends is limited to a shape that the control plane checks, which
limits form and not meaning, so a short summary can still hold a name. The text of a query goes
down to the plane, and the control plane keeps a sealed copy of it for a limited time, while a
statement a person saves is kept, sealed, until they delete it. A query’s results stay on
the plane, and a query run with rl prints its record and never its rows.
Security says how that connection is protected on our QA
deployment.
What stays in your account
On a plan with a plane in your own account, your tables’ files stay in your own bucket, in an open table format, so what is stored is not in a format only we can read. Registering your own encryption key is built in the console and is not switched on yet, so today the keys are the ones the plane’s own setup and the control plane’s role create in your account. It is offered only for an AWS plane in your own account. A key you register cannot be swapped in one step: you can take it back, and register another, only until the project’s first environment is bound to a plane. It has not yet been tried against a real key.
Which clouds
A plane is built for AWS today. The Google Cloud module is written and plan-tested in CI but has never been applied to a real project. The Azure module is the same: planned in CI, never applied to a real subscription. RunningLake does not register a plane on either yet.
Which engine runs a query
You never pick an engine, a table format or an instance type. Today a query from the console or from rl runs on Trino on a plane that reports it, and on DuckDB, in a sandbox of its own, on one that does not. Trino reads only a sample dataset, not your own tables, so a plane whose DuckDB reads your own tables keeps DuckDB for a query; the query’s record names the engine and the reason.
Where to go next
- Start here binds an environment to a plane and runs a first query.
- Security is the longer account of the boundary between the two halves.
- The security page in these docs walks each trust boundary in plain words.
- The rl command line documents
rl plane preflight, which checks your AWS account before you build a plane.