Data tables

Data tables hold durable runtime data. They are different from TypeScript Values and class fields: source values are recreated with code, while table rows survive process and worker restarts. Local table state lives outside Git; hosted table state belongs to the selected workspace. Do not expect a repository clone alone to contain table rows.

Choose global or project scope

Open Data Tables in the left rail and select a scope before creating a table:

• Global tables belong to the active workspace and can be attached to more than one project.
• Project tables belong to one project and are isolated from other project scopes.

The selected scope applies to table creation, the SQL editor, the schema diagram, relationships, and saved views. Switching scope clears open forms and query results. Inside a project's Data tables tab, create project-owned tables or attach existing global tables. Detaching a global table removes the project reference; it does not delete the workspace table or its rows.

Define and edit a table

Create a name and columns, then choose the storage mode. SQLite is recommended when you need typed columns, SQL, relationships, or saved views. KV stores opaque JSON records. Storage mode cannot be changed after creation.

Every row includes an immutable ID, a version, and created/updated timestamps. Inserts validate the declared columns. Updates use the row version so a stale editor receives a conflict instead of overwriting newer data. Deleting a table permanently deletes its rows; detaching and deleting are different actions.

Query and relate SQLite tables

The SQL Editor runs read-only SQL against an isolated snapshot of the selected scope. It cannot read workspace internals, Variables, or tables from another project scope.

The Database view can connect a text column to another SQLite row ID in the same scope. Choose whether deleting the referenced row is blocked or clears the reference. SQLite validates the relationship on every insert and update. Saved views store a reusable, read-only query over a base table, allowed relationships, filters, and sorting. Edit rows in their source table.

Relationships and saved views require hosted SQLite tables. A local/offline backend reports them as unavailable instead of pretending they were saved.

Use the HTTP API

Open a table and select API to copy its current URLs and example requests. Cloud URLs identify the workspace and table; a table keeps its global or project scope as server-owned metadata. Local Studio uses its local project routes. Available operations cover schema reads, row listing and insertion, versioned row updates, deletion, bulk mutation, and read-only SQL.

Use a workspace service token on a trusted backend for private data. A public browser token is limited to data:read and exact HTTPS origins, but it still grants read access to the table to anyone who obtains it. Use one only for data intended for public consumption. An API tab does not make a table public by itself, and Variables or credentials never belong in table rows.

Project-restricted credentials cannot escape their project by changing a URL or query parameter. Reading requires data:read, row changes require data:write, and table/schema management requires tables:manage.