Changing a field's type: what converts, what refuses

Open the field (Edit field… in its header menu) and pick a different type. Every pair that has an honest reading will run, and the dialog tells you what it costs before it happens. A pair with no honest reading is refused by name, out loud, rather than greyed out in silence.

Free: the same storage, different clothes

Some types are one kind of value differently dressed. Swapping within a family changes no stored data at all:

• The text family — single line text, long text, email, phone, web address, and the single member field, which is a text column holding an email.
• The number family — number, currency, percent, rating, duration. The stored number stays; 45 starts reading as $45, or 5400 seconds starts reading as 1:30.

Settings survive the trip, too: convert currency → number → currency and the $ comes back, because the field's options aren't wiped by a costume change.

Converting: it runs, and it tells you the cost

A conversion that rewrites the real column shows you what will happen to your values first, counted against the actual data — then runs all-or-nothing. It never leaves a table half-converted.

Out of text, which is the hub every other type reaches through:

• → number. Values that aren't numbers are cleared, and the dialog counts them first.
• → checkbox. yes, y, true, t, 1, on and checked tick the box; anything else stays unticked.
• → date. Dates written like 2026-08-09 convert.
• → single or multi select. Choices are minted from the values themselves — you don't re-enter them — and the dialog says how many will be made. They arrive in the order the column first shows them, which matters: choice order is the order the field sorts in. Rearrange them by dragging, or use Alphabetize.

Into text, which always works, keeping a written form of what was there:

• Number → text, digits as digits. Checkbox → text, true or false. Date → text, written out as 2026-08-09. Select → text keeps the choice names (multi select comma-separates them); colors go, the choice list stays, so changing back is quick. Member list → text keeps the emails, comma-separated.

And the rest of the short list: number ⇄ checkbox (zero is unticked, every other number ticks; ticked becomes 1), single select ⇄ multi select.

On a very large table a conversion can take longer than Tabla allows in one go; it refuses with "too many rows to change type in one go. Get in touch and we'll run it for you." A table busy with other writes asks you to try again in a moment.

Two steps, through text

Most of what's left isn't refused so much as routed. Text is the hub, so when only the destination is a stretch, Tabla names the two-step instead of shrugging:

A date field can't become a number field in one step. Change it to text first, then to number.

That covers number → date, date → number, anything → select except from text and the other select, and select or member list → number, checkbox or date.

Refused, by name

• Anything → member list. A member is an account on this database, not a name or a choice. Converting would change what every stored value means, so it doesn't: "Add a new member field instead."
• Out of a link, and either way for attachment, formula, lookup, rollup and button. These are structure, not presentation — the type is set when the field is created, and the editor says so on the disabled entry rather than leaving you to guess.

Picking Linked records on a single line text, long text or number column isn't a conversion, and isn't refused either — it opens the same flow as Link to another table… in the column's header menu: a new link field is built beside the column and filled by matching each value against a record in the table you pick. The column stays as it is, and deleting it afterwards is its own confirmed step. The walkthrough is in linked records.

Two settings are also fixed for life whatever the type: a date field's Include time (it picks the real column type) and Require unique values.

The dependents guard

A field that feeds something else can't change storage under it. If a formula references the field, or a lookup or rollup on another table surfaces or filters by it, a converting change is refused and the refusal names the dependent — delete or adjust that first. Free swaps skip the guard because they can't break anything.

Over the API

The same rules through one call — PATCH /api/fields/:id with { "type": "number" } — same conversions, same refusals, same error sentences. See /docs/api.

The escape hatch

For a change Tabla refuses, the honest path is three steps: add a new field of the target type, copy the column over (paste handles a whole column at once), delete the old field. Slower than a button, and it never surprises you.

A link field is not one of those cases — Link to another table… on the column's own header menu is the route in, and it fills the new field as it goes (linked records).