Documentation

The workspace's no-code databases

No-code databases store your workspace's data in queryable tables, without writing an SQL schema by hand. You define tables, query them, open access through an API key, and the same database can feed both published sites and the no-code studio. This page explains how tables and queries are organized, the role of API keys, and what the public surface exposed to the applications consuming this data covers.

Tables and queries

A database groups tables; each table describes one type of record through its columns (fields). You add, modify and delete records, and you query them to return only what the application needs: filtering on a field, sorting, paginating.

Tables and fields

A table is a set of records of the same shape. Its typed fields define what each record can contain.

Read queries

Filter, sort and paginate to return only the useful records, rather than loading the whole table on the application side.

Writes

Creating, updating and deleting records, from the no-code editor or through the API depending on the rights of the key used.

API keys

An API key gives a program access to the database without going through a user account. It carries rights: which tables it can access, and whether it can only read or also write. It is the mechanism that lets a published site or a third-party service consume the data.

Aspect	What the key controls	Good practice
Scope	The authorized tables and operations	One key per use, limited to the strict necessary
Direction	Read-only or read-write	Reserve writing for keys that genuinely need it
Lifecycle	Creation and revocation	Revoke an exposed or unused key without delay

Public surface

A database's public surface is everything that is accessible via API from outside the workspace: the tables opened to a key and the operations it authorizes. This surface is the point of contact between your data and the applications that consume it.

Two first-class consumers rely on it. Published sites read the database to display dynamic content — see /en/docs/plateforme-sites. The no-code studio plugs into it to build interfaces and screens that read and write the records — see /en/docs/plateforme-studio. The same database can thus serve a showcase site in read mode and an internal application in read-write mode, provided the keys clearly distinguish the two uses.

Expose to a public key only the tables and fields meant to be seen from the outside.
Separate keys by consumer: one for the published site in read mode, another for the studio, rather than a single all-powerful key.
Treat the public surface as a contract: renaming or removing a field consumed by a site or the studio breaks their display.
Regularly audit the active keys and revoke those that no longer match a living use.

Can the same database serve a site and the studio at the same time?

Yes. The published site reads it for its content, the studio reads and writes it for its screens. Give them distinct keys with appropriate rights rather than sharing a single key.

How do I revoke one access without breaking everything else?

Since each use goes through its own key, revoking a key only cuts off the corresponding consumer. That is the whole point of separating keys by use.

Do no-code databases replace a managed database?

They cover the workspace's no-code needs: modeling, querying, exposing through an API. For heavy transactional needs or specific operational guarantees, assess whether this scope is enough before relying on it entirely.