Bases (Databases)

A base is a database. It holds your tables, and each table has fields (columns), rows (records), and views. A base lives in your account and is linked into a site to give that site its data.

Where a base sits: a base is an account-level resource — you create and edit it in the Base Editor, independent of any one site. You then link it to a site. Pages reach the base’s tables through the SDK, which fully enforces your access rules. Backend functions reach it through ctx.tables instead, which is only creator-scoped — it does not run the same access-rule engine (see below).

The shape of a base

Account
└─ Base (a database)            ← lives in your account
   └─ Table (e.g. "Customers")  ← a sheet of typed data
      ├─ Fields   (columns: Name, Email, Status…)
      ├─ Rows     (records: one customer per row)
      └─ Views    (saved filters/sorts/layouts over the same rows)

Site  ──links to──▶  Base       ← the site uses the base's tables

Tables

Each table is like a spreadsheet with typed columns. A base can have many.

Views

Filtered/sorted windows over the same rows — no data copied.

Linked to a site

A site links to a base; the base gives that site its data layer.

Creating & linking a base

Open the Base Editor from your dashboard and create a base.
Add tables, then fields (columns) with the right types, and rows of data.
In your site’s Config → Base, link the base to the site.
Read/write it from pages via the SDK, or from backend functions with ctx.tables.

Reading rows in a backend function:

// Inside a backend function — ctx.tables reads the linked base
const { rows } = await ctx.tables.getRows('Customers', { limit: 50 });

// Filtered read — a separate method; getRows has no filter option
const { rows: active } = await ctx.tables.filterRows('Customers', {
  Status: { $eq: 'active' },
}, { limit: 50 });

Not the access-rule engine: ctx.tables is creator-scoped only — if the table tracks creators, a member only sees/edits rows they created; otherwise they see everything. Rules like has_role, has_entitlement, and field-level rules are not applied here — enforce those yourself in code, or use ctx.service.tables to deliberately bypass even the creator filter.

The full field-type list, SDK read/write methods, filtering, and views are in the Tables guide.

Tables & Fields Access Rules