Skip to content

Your app's database

Tables, fields and rows: how the builder defines them, what each field type means, and how to browse and edit your data from the dashboard.

Last updated September 17, 2026

On this page

Every web app has its own database. Anything the app remembers, customers, bookings, orders, tickets, lives in a table (the builder also calls them entities). The builder defines the tables an app needs, fills them with realistic starter rows, and wires the pages to read and write them.

Tables and fields

A table has a name and a set of typed fields. The builder chooses the fields from your description and names them in a way that reads well in the dashboard. Every row also carries a few fields the platform manages for you: an id, when it was created and last updated, and who created it.

Field typeHoldsExample
stringShort texta name, a title
textLong texta description, notes
numberA numbera price, a quantity
booleanYes or nopaid, active
dateA calendar date2026-06-12
datetimeA date and time2026-06-12T07:00:00Z
emailAn email address
urlA web address
enumOne of a fixed listopen, in progress, done
jsonStructured dataan address with street, city and postcode

A field can be marked required, and an enum field lists its allowed values. Both are enforced when a row is created or changed, from the app, from the dashboard and from the API alike.

The Database tab

Open Database in the dashboard to see every table with its row count. Open a table to:

  • Browse rows, page through them, and search within the page.
  • Add a row with Add item, filling in each field with the right control for its type.
  • Edit a row in place, or delete one.
  • Choose visible columns so a wide table stays readable.
  • Change who can read and write the table. See Data permissions.

Each table's card also has a menu (the three dots) with:

  • View data: the same as opening the table.
  • Schema: a side panel listing every field with its type, whether it is required, its allowed values and its description, the table's read and write levels, and the definition as JSON you can copy.
  • Export CSV and Export JSON: download every row of the table, with its id and dates, as a file.
  • Delete all records: removes every row from the table after you type its name to confirm. The table and its fields stay.
  • Delete table: removes the table and its rows after you type its name to confirm. Pages, forms and functions that used it stop working until you ask the builder to update them.

Changing the shape of a table

Ask the builder: add a phone number to customers, make status one of new, active or closed. It updates the table and every page that uses it. A change to a table is a full new definition, so the builder reads the current one first and carries your fields forward.

Starter data

New tables are seeded with realistic rows so the app never opens empty and you can see how it will look with real content. Delete the starter rows from the Database tab when you have your own, or ask the builder to clear them; clearing rows always asks for your approval first.

Deleting is soft

A deleted row stops appearing but is not destroyed. It can be brought back through the API (see Entity endpoints), and the app never promises a visitor that their data is gone for good.

Working with data from code

Pages read and write tables through the SDK. See Reading and writing data from your app's code.

Was this page helpful?