Databases, views and rows

A row is a page. A database is a set of pages seen as a table, and every row in it is a whole page — with a body you write in, an icon, comments, a history and a link of its own. Everything on this page follows from that one sentence: a row can already live somewhere else, a row can belong to two databases at once, and taking a row out of a table is a different act from deleting it.

A view is a saved way of looking at those pages: a layout, a set of filters, a sort. The database holds the data, the view holds the reading of it. Throwing a view away therefore costs nothing, and the app says so at the moment you do it.

Making a database

The + on a collection row in the sidebar — New page or database in {name} — opens a dialog with two answers: Page (“A document you write in.”) and Database (“A table of rows with typed columns.”). Name it, and it opens.

The app hangs a database off a collection, not off a page. Under a page the same dialog is titled New subpage and shows no chooser at all, because there would be one possible answer. A table inside a page is an inline database (below), and even that one belongs to the page’s collection.

A new database arrives with one table view and two columns:

The database’s ⋯ in the sidebar holds Rename, New table view, New list view and Move to trash. The symbol to the left of the name opens the icon picker.

Views

Two layouts, and the pair of buttons beside the database name switches between them.

Table draws every column and you edit the values where they stand. List draws one line per row: the title, and under it a one-line summary of that row’s non-empty values (Status: Draft · Notes: …). The summary is read-only — in the list layout you open the page to change anything, and rows cannot be reordered there at all.

A view carries no name. There is no field for one, so a database’s views are numbered in the order they were stored and labelled by their layout: View 2 · Table. The switcher beside the title lists them, and it is not drawn when there is only one, because there is nothing to switch to. The numbering is thin, and it is what makes a second view reachable: for a while a view made from the database menu could be opened exactly once, at creation, and after that only by typing its address.

Clicking a database in the sidebar opens its first view. A view has no row of its own in the sidebar.

Filters, sorts and columns belong to everybody. The filters and the sorts are saved in the view on the server, the columns in the database itself, so a filter you add is a filter your colleagues open the view into. The one thing that is yours alone is the layout on a phone — see On a phone.

Columns

A column is a binding: this database’s use of a field that belongs to the workspace. The field is the thing with a name and a type; the column is this table’s decision to show it. The same field can be a column here, a column in another database, and a property on pages that are in no database at all.

+ Add column, at the right end of the header, lists every workspace field that is not already a column here, each with its type, plus New field…, which creates a field and adds it in one step.

Every column header carries a ⌄:

Removing a column takes nothing away. The dialog says it in the app’s own words: “Every page keeps the value it already holds, so adding the column back brings the values back with it — and the field stays available to the whole workspace.” Removing a column edits this database. Deleting a field is a different act, in a different place, and that one does take values.

The view’s own ⋯, at the right end of the title row, holds two entries. The first, Fields of this database, shows two lists, and the split is the point: Columns of this database, which are the bindings you manage in the header, and Inherited, which are the fields the rows are offered anyway because the workspace or their collection offers them. An inherited field shows in a row’s properties when you open the page; it is not a column until you make it one. The second entry throws the view away — see Deleting a view, deleting a database.

Rows

+ New row makes an untitled page whose home is this database, appended at the end, and you type the title and the cells in place.

Add existing page… searches the whole workspace and turns a page you already have into a row of this database. The dialog says what that means: “The page becomes a row of this database. It stays where it is.” It does not move, it does not change collection, it gains a membership.

Two refusals are possible there, and neither of them is you doing something wrong:

• This page is already a row of this database. The rows are paged, so the search cannot know in advance.
• Permission. Adding a page needs edit on the page as well as on the database, because a row publishes its title, its icon and every bound value to everyone who can read the database. Search legitimately finds pages you may read and not edit, and hiding them would be a lie about why they are missing.

In a table, a row’s ⋯ holds Open the page, Rename, Move up, Move down, Remove from this database and Move the page to trash. In a list it holds the open and the two destructive entries only.

The grid answers the keyboard. Arrow keys walk from cell to cell, Home and End go to the ends of a row, and a row that is not on screen is scrolled into view before the focus lands on it. F2 on a row title renames it in place — which is also the Rename entry, and not a double-click, because the single click already opens the page and fires first.

Getting a row out again

This is the sharpest distinction on the page, and the row menu offers both halves side by side.

For a row this database created, remove is refused — and the refusal is a sentence, not a dead button: “This database is where the page lives, so it cannot simply leave. Move the page to a collection or another page first, then remove it here.” The database is that page’s home, and a page has to have one. That is why the trash entry is in the menu at all: without it the commonest kind of row had no way out of the table that made it.

Ordering, filtering, sorting

Order

Rows sit in the order you put them in. Drag the grip at the left of a row, or use Move up / Move down in the row menu — one mutation, two triggers. The menu rows exist because a phone browser raises no drag from a finger and has no arrow keys either; they were added on 13 September 2026, with the same rows for the block menu in the editor.

A sort switches ordering off. While a view is sorted, position means nothing, so the grip and the two move entries are not drawn. Clear the sort and they come back.

Filters

Filters are chips in a bar under the title. + Add filter offers the columns of this view; each chip is a field, an operator and, where the operator needs one, a value typed the way the field is typed — a date picker for a date, a member list for a person, a checkbox for a checkbox.

Five operators: is · is not · contains · is empty · is not empty.

From the second chip on, a switch appears: Match all or Match any. With one filter the two mean the same set, and a control whose settings do nothing is a control that teaches people it does nothing. It sits after the chips, because that is where the sentence they make ends. Match any arrived on 20 August 2026; views saved before it read as Match all, which is what they always did.

Two chips say out loud that they are not deciding anything, and both used to do their damage in silence until 17 August 2026:

• A chip with no value yet is marked no value and is skipped on the way to the query. An empty contains is not “match everything” — it compares against nothing, and rows that never carried the field would drop out. Measured at the time: three rows became one, with nothing on screen saying a value was missing.
• A chip whose field has been deleted is drawn in red — “This field no longer exists, so the filter can never match. Remove it with the ×.” Deleting a field takes its value off every page, so the filter could never be true again; before the marking, a database with two rows read No rows yet.

A filter may point at a field that is no longer a column. That one keeps working, keeps its name and keeps its value editor, because the pages still carry the value — it just is not offered in the + Add filter menu any more.

Sorting

One sort, one field. Click a column header to cycle it (none → ascending → descending → none), or name the direction in the Sort button or the column menu — the menu says the direction instead of cycling through it, because a menu entry that means something different on every open is a worse control than two that always mean what they say.

Rows with no value in the sorted column go to the end in both directions, and rows that tie keep their positional order.

Not every type can be sorted. Text, URL, number, select, date and checkbox have one global order and are offered. Multi-select, person, relation and formula do not, so they carry no sort affordance in the header and do not appear in the Sort menu.

Required values

The * beside a column name means a value is asked for when a page joins this database — and that, exactly, is what it means.

• + New row on such a database opens Fill in the required values first (“This database asks for these before a page can join it.”), and creates the row with the answers. Cancelling creates nothing, and nothing is lost, because there was never a row.
• Add existing page… asks the same question for a page that does not already carry the values, and does not ask about the ones it does.
• A later edit is not checked. Clearing a required cell on a page that is already a row goes through. Marking a column required draws the * and asks at the door; it does not lock the cell afterwards, and no client is refused one.
• A required relation or formula column asks for nothing at all. Neither type stores its value the way the check reads, so the flag is advice on those two.

Until 20 August 2026 the * announced a rule with no way to satisfy it: + New row answered a validation error and the button simply did not work.

Inline databases

/database in a page inserts a database and a table view of it, drawn inside a bordered box that scrolls in itself. It is the same screen as a full view, with the same header, filters, cells and row menus — the difference is where it sits. The new database is called Inline database until you rename it, and it belongs to the collection the host page is in.

Deleting a view, deleting a database

A view is cheap. The view ⋯ → Move this view to trash takes the layout, the filters and the sorts, and nothing else: “The database and every row in it stay exactly where they are.” Be deliberate about it, though — a view is not listed in the trash and cannot be restored from there. It carries no name to show in a list, and making another one is one click, so New table view is the way back.

A database is not cheap. Move to trash in the sidebar hides the database, its views and the pages that live in it: “You can restore them from the trash.” Restoring brings back exactly what went in with it. A page that was already in the trash before the database went stays there, and a page that is a row but lives somewhere else is not trashed at all — it goes on being a page, and comes back as a row when the database does.

On a phone

A view draws its saved layout below tablet width: a table stays a table and scrolls sideways inside its own scroller. The saved view is the view, and a phone quietly showing something else would make the switcher a lie.

What changes is who owns the choice. Since 13 September 2026 the layout buttons on a phone write to the address bar and never to the server. It survives a reload and travels in a link you send, and it is nobody else’s business, because it is not in the database. Everything else — filters, sorts, the match switch, the columns — stays exactly as shared as it was: those are about the data, and the layout is about the screen.

The row grip and the row ⋯ grow to a 44 × 40 pixel target on a coarse pointer — as wide as a thumb needs and as tall as the row is — and the moves live in the menu because a finger raises no drag.

What databases cannot do yet

• Table and list are the layouts. There is no board, calendar, gallery or timeline.
• A view has no name and no grouping. Views are numbered and labelled by layout; rows cannot be grouped under headings.
• A view cannot hide a column. Which fields a view shows is the database’s column list, shared by every view of it. Removing a column removes it for everyone.
• One sort at a time, and multi-select, person, relation and formula cannot be sorted at all.
• Filtering a relation or formula column does not work, and it is not refused either: the chip can be added, but neither type keeps its value where the filter reads, so is not empty matches nothing and is empty matches everything. Filter on a column of another type, or open the pages.
• No formula column you can create. Formula and relation are read-only, server-computed types, and the New field form does not offer them. Every workspace does hold one relation — the built-in Related pages — and you can add it as a column; a formula field can only be made through the API.
• A column’s default value can only be set through the API. A binding can carry one, and a default satisfies a required column, but no screen writes it.
• Column widths are fixed at one width for every column, and there is no drag to change them. A long value is truncated with the full text in its tooltip.
• A trashed view is gone. It is not listed in the trash; make a new one.
• Rows are not editable in the list layout, and cannot be reordered there. Switch to the table, or open the page.
• No bulk edit. There is no multi-row selection, so removing, trashing or filling in five rows is five rows of work.