BUILDING Parts of this page describe what is not built yet, and each says so.

Start here

From nothing to your first query. Every command and file on this page is run by our own tests, so each does what it says. Where something is not built yet, the page says so instead of showing a command that would fail.

1. Get access

RunningLake is in early access. Ask for access; when we have added you, sign in to the console with Google. The console creates your organisation and your trial the first time you sign in, and you are its owner.

2. Sign in from your terminal

The console does everything on this page. rl, the command line, does most of it in a script. There is no public download of rl yet; ask for it when you ask for access.

Create an API token in the console, under API tokens. Then point rl at the control plane and log in. It asks for the token without showing it, checks it with the control plane and keeps it in your operating system’s keychain. In CI, set RL_TOKEN instead; it always wins over the keychain.

export RL_SERVER=https://swim.runninglake.com
rl login

The address in that sample is our QA deployment. There is no production service yet.

3. Create a project

A project holds your environments and your files. This one is called payments.

rl project create -name payments -region us-east-2

It prints the project’s id, where it lives and its two environments, dev and prod. The region is where the project’s data lives, and it is the one choice here that is hard to change later; leave it out and it is your organisation’s home region, which is printed either way. In the console the same thing is on the Overview. Organisations, projects and environments says what each of these is.

4. Connect a data plane

An environment holds nothing until it is bound to a data plane, the Kubernetes cluster where queries run and files live. In the console, Planes lists the planes your organisation has and walks you through connecting one in your own AWS account; rl plane preflight checks that account before you build it. When a plane is connected, choose it for the environment on the Overview. A plane can only serve an environment in the same cloud and region as its project. The data plane and what stays in your account says what is where.

5. Declare your first table

A table is declared as a file. In an empty directory, save this as tables/orders.yaml:

apiVersion: runninglake.io/v1alpha1
kind: Table
metadata:
  name: orders
spec:
  namespace: [bronze, sales]
  table: orders
  routing:
    format: ICEBERG

A table has one format, chosen when it is created and fixed for its life. Iceberg is the only format a table can be created in today. Then, from that directory:

rl diff
rl plan -project payments -env dev
rl deploy -project payments -env dev
rl get -project payments -env dev table orders

• rl diff checks the file offline, exactly as the control plane would, and sends nothing.
• rl plan shows the change set that the file makes in dev.
• rl deploy plans again and submits it. dev applies a change at once; prod would wait for an approval (Review and approval).
• rl get reads the table back as the control plane holds it, with the state its plane has reached.

The control plane asks the plane to create the table in its catalog. The table exists and has no rows: no plane turns an uploaded file into a table yet, so a file you upload, in the console or with rl volume upload, stays where it was put.

6. Run your first query

rl query -project payments -env dev "select 1"

rl submits the statement to the plane the environment is bound to and watches it to the end. It prints the query’s id and status, each change of status, the engine and the reason it was chosen, and the record at the end: rows out, CPU, memory and how long it took. It never prints rows, because results stay on the data plane; the SQL workspace in the console shows them.

You did not choose 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 serves it, and on DuckDB, in a sandbox of its own, on one that does not; the query’s record names the engine and the reason. A statement that would write is refused, because tables are declared in files and not created by SQL. select 1 reads nothing of yours, which is the point of it: it exercises the whole path, from rl to the control plane to your plane and back.

7. Read the bill

A finished query’s record carries what it used against your plan’s compute cap, in vCPU-seconds, and, when it could be priced, its price at the cloud’s list rate, in dollars; a query that could not be priced says why. Once your cloud provider’s own bill has been read, it also carries the bill’s figure, which replaces the list price. There is no credit unit anywhere: every figure is in dollars, or in the unit your plan caps.

The Cost page in the console says what applies on your plan. On the trial everything is included and it shows no dollar figure, because the trial is not money you owe. On Team it shows your planes’ standing cost this month, as your cloud’s bill filed it and before the management fee, on a line of its own. On Business and above it shows the same line and never charges it: your cloud bills you directly, and the line is what that bill should reconcile with.

Not built yet

• None of the four agents is built yet, so nothing writes a pipeline for you.
• Trino reads only a sample dataset, not your own tables. A plane whose DuckDB reads your own tables keeps DuckDB for a query, and the record says that is why, until Trino reads the catalog.

The rl command line has every verb, flag and exit code.