Tables

Tables hold the data everything else in Ronja is built on. Every table lives in a feature (with one scratch-pad exception — see Session tables below), has a kind that says where its data comes from, a build lifecycle that keeps it fresh, lineage that connects it to the rest of your data estate, and a trust state that says whether the organization stands behind it.

The four kinds

Each table wears a kind chip, and the product explains each one in a sentence:

Kind	What it means (product copy)
Foundation	“Cleans and standardizes raw source data into a reliable base layer.”
Integration	“Synced from an external connection — its shape mirrors the upstream system.” (Tables updated by uploading files directly also display as Integration.)
Derived	“Built from other tables as inputs with SQL.”
Dynamic	“Written to directly by agents as they run.”

The kind decides what you can do on the table page. Derived tables expose their code — a tab alongside Data, Columns, and Checks — because they’re defined by a query over inputs. Foundation, Integration, and Dynamic tables hide per-table build controls.

Builds

A table’s contents are produced by a build. On the table page you’ll see its state at a glance: a status dot, “Building table…” while a build runs, and banners when something needs attention. If the table is due a rebuild it hasn’t run yet, you’ll see “This table’s data is stale”. A table built from several inputs that is deliberately waiting for its remaining inputs to catch up — or, for at most about 15–20 minutes, for an input whose sender is still sending related tables over the API — reads Ready with no banner — the Data map’s Builds lens is the one surface that shows that wait — and the stale banner appears only once the table is actually due its rebuild. If a rebuild itself failed, you’ll instead see “Build failed” with an expandable error, or — for a table that still has data from an earlier build — a banner saying how old that data is and since when updates have failed (see When a table stops updating). Every one of these banners carries a rebuild affordance for Admins — except the missing-input banners below, where a rebuild can’t help; only the two build-failure banners, and a missing-input banner explaining a failed build, carry an Investigate with Ronja button, which opens a Build-mode exploration already diagnosing that table’s failure — see Fix data issues.

When a table this one reads is gone, the table page says so with its own banner. If an input was deleted for good — on its own, or with its Feature 30 days after that Feature went to the trash — the banner reads “This table can’t update: an input it reads was deleted.” and, when Ronja knows it, says which day its data is from. Edit the table’s recipe and its inputs together to replace or remove that input, or delete the table if nothing needs it. A Derived table stops updating when any table listed among its inputs is deleted for good, even one its recipe no longer reads; an input that is only in the trash is covered below. Within an hour of the input being deleted, Ronja also tries to update the table once; that update fails, so the table reads Build failed wherever it appears while keeping its data, and, for a table that has held data, the people responsible are told with a Table not updating notification (see When a table stops updating). A table that never held data and stays Build failed goes to the trash after 7 days. If an input, or the Feature it belongs to, is in the trash, the banner depends on whether the table’s last update failed because of it. If it did, the banner reads “This table can’t update: an input it reads is in the trash.” and, when Ronja knows it, says which day its data is from: restore the input from Trash to get the table updating again. Otherwise it reads “An input this table reads is in the trash.”: restore it from Trash to keep the table updating, because once it is deleted for good the table stops updating. While this banner explains a failed build, the other build banners are not shown and there is no rebuild action, since a rebuild can’t bring the input back; for Admins with Build mode the banner carries Investigate with Ronja instead, which can edit the recipe for you. A build that failed for any other reason still shows its own banner below it. Ronja is told the same when she looks the table up.

When an input was built or written and simply holds zero rows — a filter that matched nothing, or a restore to a version saved with zero rows — the Derived tables built from it rebuild to zero rows, keep their columns, and read Ready. A Dynamic table that has never been written to, or was just cleared, is different: a clear removes its data and its column types, so there is nothing to build from, and the Derived tables keep their earlier data until the next write.

A table can’t read from itself, directly or through other tables. An edit that would make it do so is refused, with the loop named, and a table already caught in such a loop shows Build failed until the loop is broken: remove an input that is part of the loop — from this table or another table on it — and commit the change.

A Derived table written in SQL is built as one file of at most 2.5 GB, from input tables holding at most 4 GB in all. A build over either limit is refused with an error that names it. Over the 2.5 GB output, split the table into smaller tables (by a date range, for example), or narrow its SQL to fewer rows or columns. The 4 GB input counts each input table’s whole size, whatever the SQL reads of it, so narrowing the SQL does not help there: build the table from fewer or smaller input tables.

A Derived table written in SQL lists its columns in alphabetical order — capital letters before lowercase ones — not in the order its SQL names them, and the fields inside a nested column the same way. So a query that reads a table by column position, such as SELECT * in a UNION ALL with another table, should name its columns instead: if the order ever differs from what the query expects, the wrong columns line up without an error wherever their types match.

When a table stops updating

A table whose rebuilds keep failing doesn’t go empty: it goes on answering with the data from its last successful build. So that a table stuck for days never looks healthy, Ronja keeps a record of when its updates started failing, and it survives every retry until a build succeeds again.

On the table page, the banner reads “Showing data from today at 09:14. Updates have failed since Monday at 06:00:”, followed by the reason from the latest attempt — click the banner to read all of it. When Ronja has no record of when the table last had data written to it, the banner starts at “Updates have failed since …”. The Refresh action (Admins) and Investigate with Ronja sit on it as on the other build banners. A table that stopped because an input is gone shows the missing-input banner instead (see Builds), and reads Build failed rather than Not updating in lists and on the Data map; its notification is the same.
On the Feature’s table list and on the Data map, the table carries a Not updating marker. Hover it for the same “since” and reason.
When Ronja answers from the table, she is told it has stopped updating and why, and the table’s entry under Sources in her answer is badged not updating, with the reason beside it.

The banner and the marker clear on their own the next time a build of the table succeeds. A table that has never built successfully shows Build failed instead: it has no earlier data to fall back on.

Ronja also tells the people responsible. Once a table’s updates have been failing for 30 minutes, a Table not updating notification goes to the maintainers of its Feature — or, when the Feature has none, to its owner for a private Feature, or to your Admins — in the Notifications bell in the sidebar. The banner and the Not updating marker appear as soon as an update fails; the notification waits, because most failures clear on the next automatic retry — a table that recovers within 30 minutes sends none. It is sent once per stretch of failures, not once per failed attempt, and at most once a day for any one table: if the table recovers and later fails for 30 minutes again, the next notification comes no sooner than 24 hours after the last. A table that has never built successfully sends none — it has no earlier data, and its page says Build failed. That in-app notification always arrives; to have it emailed or sent to Slack as well, an Admin turns Table not updating on under Notification routing, in the Verification group, and chooses who receives it and on which channels. A table in a private Feature is the exception: its notification stays in Ronja, for the Feature’s owner, and is never emailed or sent to Slack, because the reason can quote the table’s own data.

When a workflow’s inputs move on

A Dynamic table that a workflow writes is not rebuilt when the tables it read change — nothing runs until the workflow runs again. So the table page says where its rows came from. Under the build banners, a table a workflow has written carries one quiet line: “Built by workflow · inputs unchanged”, with the workflow’s name as a link. If the workflow read no Ronja tables at all, the line says so — “reads no Ronja tables” — rather than claiming they haven’t changed. And if every table the workflow read is one it also writes, there is nothing outside the run to compare against, so the line reads “Built by workflow · reads only tables it also writes” instead.

When one of those inputs has been written to since the run read it, the line turns amber: “Built by workflow from input before it changed · 2h ago”. It names the first input that moved (and counts the rest), and if the input has since been deleted it says that instead. The rows are exactly what the run produced; they just no longer follow from what the inputs hold now. It is advisory — the table is still queryable, apps still read it, and nothing is blocked. If you want the table brought up to date, run the workflow; the line clears on its own once a run has read the inputs again. A deleted input is different: a run would fail at the missing table, so the workflow needs attention first.

Three cases make the line stop giving a verdict, and each says why, so a verdict you saw yesterday never just disappears. “Written since by something other than workflow” means rows were pushed into the table after the workflow’s run — from an app, over the API, or in a chat — so the run no longer describes what the table holds; the next run of the workflow restores the verdict. “Written by more than one workflow, most recently workflow” means two workflows have appended to it, and no single set of inputs accounts for the rows; that line stays until one of them replaces the table rather than appending to it. “Built by workflow · whether its inputs have changed since is unknown” means Ronja has the run’s record but cannot compare it against the inputs — rare, and nothing to act on.

A Derived table built from such a table shows it too: the stale table’s chip in its Inputs list carries a small amber mark — hover it for the reason — so a stale source upstream is visible even where the downstream build itself succeeded. Ronja sees it as well: when she queries a table in this state, she is told.

The reporting timezone

Beside those badges, a Derived table shows the reporting timezone it is built on — for example Europe/Stockholm — when it has one. That’s the calendar Ronja groups by when the table rolls data up per day, week, or month, so an order placed at 23:30 lands on the day it belongs to locally rather than on the next day in UTC.

It matters most for month and quarter boundaries: the same query grouped on two different calendars puts invoices dated the 1st in different months. Fixing the calendar to the table means everyone reading it sees the same numbers, whatever timezone their own browser is in.

New tables take your organization’s timezone (set by an admin on the Organization rules page in the admin area) and keep it from then on — changing the organization default later doesn’t quietly move the calendar of tables you’ve already built. If your organization hasn’t set one, new tables simply don’t declare a calendar and group by UTC, exactly as tables did before this existed. Tables built before your organization set a timezone are left alone too — nothing was quietly relabelled. Like the other build settings, it’s read-only on the table page. To change it, ask Ronja in chat: she stages the change as a draft, rebuilds it on the new calendar so you can check the result, and only then publishes it.

Because it’s fixed when the table is created, the organization default is worth setting before people start building — otherwise tables built earlier and later sit on different calendars. That matters when two tables are combined: if one groups by month on UTC and the other on Europe/Stockholm, rows near a month boundary line up against the wrong month, and nothing reports an error. If your organization changes its timezone, it’s worth asking Ronja to re-check the tables you already rely on.

If a table doesn’t group by day, week, or month at all, its calendar makes no difference to the numbers — so this is only worth thinking about for roll-ups.

Lineage

Tables don’t exist alone. Open Details on the table page to see their connections:

Inputs — the tables a Derived table is built from. An input that lives in a feature you don’t have access to still appears, showing its name and the feature it belongs to, but it isn’t clickable — so you can see where the data comes from and who to ask. An input that is gone is still listed and isn’t clickable either: one that was deleted for good shows as Deleted table, and one in the trash — on its own or with its Feature — shows its name followed by in the trash.
Dependents — the downstream tables built from this one. When a table’s data changes — it finishes building, or rows are written to or restored into a Dynamic table — its dependents rebuild themselves automatically, and theirs after them. A change flows all the way down the chain without you rebuilding each one by hand. A script that sends several tables over the API can hold those rebuilds back until it has sent them all; the dependents then rebuild once, when it releases them or after about 15–20 minutes at most (see Send several tables at once). A table built from several inputs waits until all of them have caught up and then rebuilds once, over everything new, rather than rebuilding after each input in turn; while it waits, the Data map’s Builds lens shows it as waiting on an input and names which.
Producers — the workflows that write this table, which are also drawn between their inputs and their outputs on the Data map.

A “Show in data map” action opens the table’s pipeline in the organization-wide Data map (the Space you’re in, if your organization has more than one), and from a feature’s Inventory list, “View in graph” shows a resource’s cross-feature dependencies. Lineage is why Ronja’s answers are traceable: you can always walk from a number back to its sources.

A table’s page shows its own lineage; to see the whole picture — how this table connects to the workflows, notes, and apps around it, including links that cross into other features — open the Graph action on the feature it lives in. Inside a conversation, the same picture is one tab away — see The Map, below.

The Map

Open a table from a conversation — click its name in an answer, or ask Ronja to show it — and the table’s side panel appears. Beside Data and Schema there is a Map tab.

The Map answers one question: what is around this table? The table you opened sits in the middle. Everything that feeds it is on the left. Everything that depends on it is on the right — and not only tables: the apps, automations, saved agents, and notes that use it appear there too, each with its own icon.

Under the graph a line counts it up, for example:

Fed by 2 tables · feeds 1 table · also used by 1 app, 1 automation (2 structural)

Structural is the load-bearing count. A structural user of a table stops working without it — a derived table built from it, an app that reads it, an automation that runs against it. Everything else is a mention: a note that refers to the table still reads fine if the table goes away. That distinction is the same one Ronja uses before she lets you delete something, so the Map is showing you what would block a deletion before you try one.

The lines say how strong each link is: a solid line is structural, a dashed line is a mention, and a dotted line points a table at the workflow that produces it.

If the line ends with partial — the map stopped at its size limit, there is more neighborhood than fits: the counts are a floor, not a total. They also grow as you expand the map, so read them as “at least this much”.

A table with nothing around it says so: Nothing connected yet.

Walking the map

Click any table and the panel re-anchors on it — the map redraws around your new table, and the panel’s back arrow returns you to where you were.
Click an app, workflow, or metric and it opens in its own panel. Kinds without a panel of their own open on their page instead.
A “+” on a node at the edge of the map pulls in one more hop on that side. The map starts one hop out in each direction and expands up to four.
Anchor on another table searches by name. Picking one re-anchors the map on it. Searching never changes your conversation — that is what the attach buttons are for.

A table you can’t see

Some tables belong to features you are not a member of. Those keep their place on the map, with a lock and the words Restricted table instead of a name: you can see that something feeds this table, and how strongly, without seeing what it is called. A locked node cannot be opened and cannot be attached.

This is deliberate. A map that quietly dropped the tables you cannot read would tell you a table has one input when it has three, and “nothing depends on this” is exactly the answer that invites a deletion.

The lens

Lens paints the tables on the map with the answer to one question:

Freshness (the default) — whether each table’s data is as recent as it should be, under the same rule the Data map uses: 30 days without new data for a table that loads from outside, the declared window for a table with a freshness health check, its inputs for a table built from other tables, no judgement at all for a Foundation table unless someone declares a check on it, and never for a table marked never stale. A table inherits its stalest input’s red, so a problem upstream shows up on everything downstream of it. A dashed outline marks a table with a freshness health check; when that check is failing, the outline turns red, and the tooltip adds it in words: Its declared freshness check is failing.
Usage — how much each table is read, over the last 90 days. Based on recorded queries, so a table someone previews but never queries reads as unread. Working out a metric counts as a read of the metric, and keeps the table it reads counted as in use, though it does not make that table more popular.
None — the plain map.

Tables are painted, and so are the metrics built on them — under Usage a metric is coloured by how much it is worked out. An app or an automation keeps its own icon and color, because the lens has no opinion about it. A table the lens has no figures for is left unpainted and counted on its own line under the lens, so a missing color never reads as a good one.

A table sitting at the edge of the map has inputs nobody has walked yet, so under Freshness its hover text says no cause is claimed rather than colouring it green — pull in another hop with the + on its input side to get a full verdict.

Putting tables in the conversation

The Map is the fastest way to get the right tables in front of Ronja when you know the neighborhood of a table but not the names in it.

Attach table to chat attaches the table the map is anchored on.
Attach inputs (n) attaches its direct inputs in one go.

Attached tables appear as chips above the message box and travel with your next message. Browsing the map — clicking through it, searching it — never attaches anything on its own. Where you can’t send messages, there are no attach buttons; the map is there to be read.

Trust

When several tables have nearly the same name, the useful question is which one the organization actually stands behind. An Admin answers it from the Governance · admin only panel: on the table page, open Details, then expand Table governance. Verify endorses the table’s definition and gives it a green Verified badge; Retire flags one as historical and pushes it down in search.

After that, Ronja watches the definition. If it changes — a Derived table’s calculation, or a Foundation, Integration, or Dynamic table’s source binding or column shape — the badge turns amber “Verified · review pending” until an admin Acknowledges the change. Extra rows alone never count, so a daily refresh leaves a verified table cleanly verified; a column being added, dropped, renamed, or changing type does.

An unvetted table carries no badge at all, so a badge on a table page always means something. In Search (⌘K), a verified table comes first and a retired one last among results that match your search equally well; when Ronja searches during a chat, verification shifts how relevant she judges a table to be, so it can change which one she reaches for. The full picture, including what applies to metrics, is on Verification.

Health

Trust is about the table’s definition. Whether its data is still right is a separate question, and it has its own tab: Checks. Ronja writes a check or two when she builds a table — “orders always have an id”, “this table has rows” — and re-runs them on every build, so a pipeline that quietly stops delivering rows is caught rather than silently believed. A failing check shows a banner on the table page and never blocks anything, and every table with an active check carries a status marker in its feature’s table list and at the top of the table page. See Health checks.

Names

A table’s name has to be unique inside its feature. Capitalization and spaces around the name don’t count, so Orders and orders are the same name, and so is orders with a stray space on the end. Metrics share the namespace with tables, so a metric can’t take a name a table in the same feature already has.

The same name in a different feature is fine — Sales and Billing can each have a customers table. Session tables (see Two special cases below) aren’t in a feature, so they’re exempt.

A name you choose in the app also has to be a name Ronja can use as a handle: no full stop, no double quote, no @, not all digits, and not something shaped like one of Ronja’s internal ids. This applies when you pick a name or change one — a name that’s already there is never refused after the fact, so tables that predate the rule keep working exactly as they are.

If you try to save a name that’s already in use, Ronja refuses the save, tells you which table has it, and leaves what you typed in place. Moving a table into a feature that already has a table by that name is refused the same way — nothing is moved. Archiving a table or putting it in the trash frees its name for something else; if you bring it back and the name has been taken in the meantime, Ronja restores it under a slightly different name rather than leaving it stuck in the trash.

Referring to a table by name

Because the name is unique, it can be used to point at the table. It is written one of three ways:

Sales.orders — the orders table in the Sales feature. This is the everyday form.
orders on its own — the orders table in the same feature as whatever is doing the referring. Inside an exploration it also finds that conversation’s own session tables.
private.Sales.orders — a table in your private feature called Sales. Someone else’s is "them@example.com".Sales.orders.

Put double quotes around any part that contains a full stop: Sales."v2.1 forecast".

Where a name works. Wherever SQL or code is saved: the {{ ref(...) }} references in a Derived table’s calculation, and the same references in a workflow’s files — from the app, or over the API. It also works wherever you name a table to Ronja in a conversation, since she saves what she writes.

Where it doesn’t. A query you run yourself takes the table’s ID: ronja query from the CLI and POST /api/v2/duckdb/query resolve the {{ ref(...) }} marker straight to the table’s data, and never look a name up. The ID is in the table’s URL in the app, or from GET /api/v2/search?q=orders.

From a CLI folder, declare the name first. ronja wf push, ronja pipeline push and ronja sync check refuse a {{ ref('Sales.orders') }} the folder hasn’t declared under dependencies. That is not the server disagreeing — it is the folder protecting itself: Ronja stores the ID, so a file that kept the name would read as changed for ever with nothing you could edit to fix it. Declare the name in ronja.json and bind it, or write the ID. See Dependencies: naming the things your code reads.

A name is turned into the table’s ID the moment you save, and the ID is what’s stored. So renaming a table afterwards never breaks anything that already points at it — the reference was never holding the name. It also means what you read back is the ID form, which is the same reference written the way it’s kept.

A name on its own is only ever looked for in the feature doing the referring, never across the whole organization — so a table of that name somewhere else is never a silent match. If nothing there answers to it, Ronja refuses the save, and where the name does exist elsewhere she lists what would have matched: “did you mean Sales.orders or Billing.orders?” — written the qualified way, ready to copy.

If the feature part of a name matches more than one feature you can reach — an organization feature called Sales and a private one of your own also called Sales — she refuses and names both rather than picking one.

Reading a table

The Data tab opens first. It shows the table’s rows, with search and filters for the rows loaded in the grid. For larger tables this is a preview, not a search across the entire table; the note above the grid explains its limits. Use Explore table to ask Ronja questions about the full table.

Open Columns for column types, descriptions, and statistics, or Checks for data health. Derived tables also have a Query (or Code) tab showing their definition. Details brings together the table’s explanation, knowledge, inputs, dependents, producers, and settings. Activity shows builds and saved versions on live tables; it is unavailable on drafts and historical versions.

When a column changes type

A Dynamic table is written to directly — by Ronja, by a workflow, or by your own code over the API — so its columns are whatever the writes carry. Sooner or later a write carries a column typed differently from the one already stored: an id that was always a number arrives as text, a date arrives as a date and a time.

Ronja doesn’t refuse the write. She widens the column to a type that holds both, and the rows land. A whole number meeting a decimal reads as a decimal; a date meeting a date-and-time reads as a date-and-time; anything meeting text reads as text — except binary data, which stays binary when it meets text. Nothing already in the table is rewritten — the column simply reads as the wider type from then on.

When the two types can’t be read together at all — a date meeting a number, say — there is no wider type to move to. The values in that write are stored as text instead, and the column reads as text from then on; the rows that were already there are untouched. This is the case worth knowing about, because a query that did date arithmetic on that column now has to convert it first.

A few column types can’t be rewritten as text, and for those there is nothing left to try: a decimal, a time-of-day, a timestamp written in the legacy format some older tools still emit, or one of the rarer binary-encoded types — a half-precision float, an interval, a geometry or geography value, or a BSON document (the binary form of JSON that MongoDB and some other databases export). When one of those is the column that can’t be read alongside what the table holds, the write is refused with a 400 naming the column, and nothing lands. Decimal is the one to watch — it’s what pandas and Spark write for money columns. Send that column as text, or as a plain number, and it lands like any other. A half-precision float is refused even when it meets a column of numbers — send it as an ordinary (32- or 64-bit) float.

A column that changes between a nested shape — a list or an object — and anything else is refused. The write doesn’t land and nothing about the table changes. There is no readable answer for a list sitting beside a number, so it is rejected rather than left in a state no query can read.

Either way, the write’s response names the column and says what happened to it.

Schema policy

A Dynamic table’s page carries a Schema policy control for Admins — it is not shown to anyone else — with two settings:

Widen — the default, and the behavior above.
Strict — every write has to carry exactly the table’s columns with the same types. A write that adds a column, leaves one out, or changes a column’s type is refused, and nothing lands.

Choose Strict for a table whose shape is a contract that an app or a report is built on. Leave Widen on for a table fed by a source you don’t control, where losing a batch of data costs more than a column reading as text. A nested shape against anything else is refused under both settings. Changing the setting takes the Admin role, plus write access to the table’s Feature — a step above writing rows, which any member with write access to the Feature can do.

Legacy SQL escapes

A Derived table written in SQL before Ronja changed how backslashes are read may show a Legacy SQL escapes chip on its page: its SQL was saved under the older reading, where a regular expression is written '\\s' and a new table writes '\s'. While its SQL has a backslash escape the older reading decoded (such as \1, \b, \', \\ or \n), its build is refused with an error naming the table, the escape and its line, and saying its recipe must be edited. \d, \s and other escapes the older reading left alone build as written, and most escapes inside a comment don’t count; the error names any that does. The older reading also indented every line of the SQL, so a line break inside a quoted value, a quote or comment that is never closed, or an input placeholder such as $12 that the older reading split is refused the same way; SQL with none of these builds as before. The next edit to its SQL moves it to the current behaviour, and the chip clears when that edit is published. Other kinds of table store no SQL of their own and never show it. See how backslashes in SQL are read.

Legacy typing

A Dynamic table that existed before September 2026 shows a Legacy typing marker in its details: rows sent to it as JSON are still read the older way — numeric-looking text such as "020" is stored as the number 20 and true/false as text — and every write to it says so in its response. There is no control for it on the page: the switch is made over the API — once the Derived tables that compute on those columns cast them, since the raw write is the landing zone and typing belongs downstream — or by emptying the table, and the marker disappears. See Use the API.

Seeing that it happened

A column that has been widened carries a muted line under it on the table’s Columns tab — “Widened from bool on 2026-09-12”: the type it used to be, and the day it changed. It survives rebuilds, so it still answers the question weeks later. Emptying the table clears it, and so does a write that replaces the table’s contents outright.

Ronja also tells someone when the change is one that alters what an existing query returns — a column becoming text, a true/false column becoming numeric, a new column appearing. Table column type widened is on from the start: until an Admin routes it on the Notification routing page, it reaches the table’s owner, or your Admins when the table has no owner. It arrives at most once a day per column, and a different column changing later the same day still tells you. Changes that leave every existing query working — a whole number becoming a decimal, a date becoming a date-and-time — don’t notify at all.

Changing a table safely

Edits to tables go through per-user drafts: your changes live in a draft (one per person per table) until they’re committed, and edits to shared tables by non-admins wait for review before going live. Version history lets you restore an earlier committed version. The full lifecycle is covered in Versions, drafts, and approvals; the hands-on recipe is Create tables with Ronja.

Two special cases

Session tables — scratch tables that exist only inside one exploration. In the product’s words: “This is a scratch table that only exists in this session. It isn’t saved to a feature and can’t be opened elsewhere.”
Data dictionary tables — a table can be marked as a data dictionary and linked to the tables it describes, which points Ronja at your own definitions to read when she works with those tables. It is a pointer, not a copy: it does not fill in the linked tables’ own descriptions. See Maintain the data dictionary.

For a compact comparison of the kinds — source, rebuild behavior, editability — see the table types reference.