Custom Tables

Custom tables let you create and manage structured data directly inside a Wallabi data source. They’re useful when your apps need a small, hand-managed dataset alongside the data coming from your databases and applications — mapping tables, classification lookups, configuration values, or any reference data your transforms need to join against.

When to Use a Custom Table

Custom tables are a good fit when:

• You need a lookup table — priority codes, status mappings, category labels
• The data doesn’t live in a source system — it’s something you or your team curate by hand
• You want your reference data alongside your apps — tracked and versioned, not scattered across spreadsheets

If your data already lives in a database, application, or file, connect it as a data source instead.

How They Fit In

A custom table lives inside one of your data sources. It appears in the Data Explorer, joins with other tables in transforms, and is queried the same way as any other table. The only difference is that the data comes from you rather than an external connector.

Once a custom table is in place, a transform can use it like any other table:

SELECT t.*, pm.label AS priority_label
FROM tickets t
JOIN priority_mappings pm ON t.priority = pm.code

Key Behaviors

Full edit history

Every change to a custom table is tracked — both schema changes and data changes. Nothing is ever permanently overwritten. When you “delete” a row, it’s hidden but can be restored later. You always have a record of who changed what and when.

Rename-safe columns

Renaming a column doesn’t break anything. Existing data stays intact, and queries referencing the old name continue to work — Wallabi keeps the old name as an alias.

Dev and production isolation

Schema changes and row edits made in your dev environment are scoped to that environment only. Production data is always visible while you work, but experimental changes don’t affect production until you promote them. This lets you try things out safely — add a column, load some test rows, see how a transform behaves — without risk.

Column Types

Custom tables support five column types:

Type	Example
Text	"Acme Corp"
Number	42.5
Boolean	true
Date	2026-04-15
Date and time	2026-04-15T14:30:00Z

Working with Custom Tables

Custom tables are created and managed through Claude Code. Ask it to:

• Create a table — “Create a priority mappings table with code, label, and sort order columns”
• Add reference data — “Add these priority rows: P1 Critical, P2 High, P3 Medium”
• Modify the schema — “Add a description column to the priorities table”
• Update values — “Change the label for P1 to Urgent”
• Remove rows — “Hide the P4 priority row”

Because Claude Code understands your data sources and your transforms, it can often suggest a custom table on its own — for example, when a transform contains a hard-coded list of categories that would be easier to maintain as a table.

A Typical Workflow

Setting up a priority mapping table might look like this:

1. Create the table — ask Claude Code to create priority_mappings with code, label, and sort_order columns
2. Add the reference rows — ask Claude Code to insert the priority values
3. Use it in a transform — join tickets to the mapping to get human-readable labels
4. Adjust over time — rename a label, add a new priority, or hide a column as your needs evolve

Each change is captured in the table’s history, so nothing is lost if you need to look back or undo.

What’s Coming

Custom tables are new. Today they’re managed through Claude Code; we’re adding:

• Direct editing in the Wallabi app — create tables, edit columns, and manage rows from the Data Explorer
• Live editing from data apps — so your apps can let users update reference data themselves
• Environment promotion UI — a visual workflow for reviewing and promoting dev-scoped changes to production
• Version history browser — step through past edits and restore earlier versions