What makes a Zanbase table a real database

Plenty of tools give you something that looks like a database: a list of pages with a few columns bolted on. It works right up until you ask it to do database things — compute a value, summarize linked records, or show the same rows as a board and a calendar. Then the seams show.

A Zanbase table is the real thing. Here’s what that means.

Typed columns, not free text

Every column has a type — text, number, date, select, relation. The data behind them is structured and validated, so a “date” is a date you can put on a calendar, and a “relation” is a real link to another row, not a pasted string.

Formulas and rollups

Columns can compute. A formula derives a value from other columns in the same row. A rollup summarizes linked records — sum the invoices attached to a client, count the open tasks in a milestone — and stays current as the underlying rows change.

• Formulas evaluate live, with dependency tracking
• Rollups reach across relations to aggregate linked rows
• Results are projected onto the row, so views read them like any other cell

One dataset, many views

Because the rows are structured, any view can render them — the same data as a table, a board grouped by status, a calendar on a date column, or a gantt across a start/end pair. You don’t export and re-import to switch. You point a different view at the same rows.

That’s the payoff of “real”: the data isn’t trapped in a format. It’s a database first, and every view is just a lens over it.

Part of the workspace, not a silo

A table sits in the same sidebar as your docs, projects, and channels, and obeys the same permission model. Embed a view in a doc, link rows to a project, or feed a table from a public form — the data stays one source of truth.

Build a table and see where a styled list would have stopped.