Skip to main content
Your project’s database is where your bot keeps everything it remembers. Tools → Database is where you get to look at it: browse the tables, correct a wrong value, pull a table into a spreadsheet, or ask a question of the data directly in SQL.

​
Preview and Production hold different data

The toggle at the top of the tab is the most important control on the page.
  • Preview is your testing data — whatever your bot recorded while you were trying things out.
  • Production is your real data — actual customers, actual bookings.
They’re two separate sets of rows. A booking you made while testing isn’t in Production, and a real customer’s booking isn’t in Preview. The tab opens on Preview, so if you’re looking for a real customer’s record and can’t find it, check the toggle first.
In Production you’ll see a Data only badge. That means you can’t change the shape of the database there — no new tables, no new columns, no dropping anything. Those changes belong in Preview, and reach Production when you deploy. You can still fix the rows in your own tables.

​
Browsing and editing

Select a table to see its rows, 50 at a time. From there:
  • Edit a value — double-click a cell (or tap it on a phone).
  • Add or delete a row — Add Row, or the bin icon on a row.
  • Clear a table — Clear empties every row but keeps the table itself.
  • Filter — narrow rows by a column using equals, not equals, contains, greater than, or less than.
  • Change the shape — New Table, Add Column, and Drop Table, in Preview only. On New Table you have to tick PK on one of the columns; the form won’t let you create the table until you do, and says why: Tick PK on a column — a table needs a primary key to be editable.

​
A table needs a primary key to be editable

Paige identifies a row by its primary key, so a table without one can be read but not changed. Open a table like that and instead of the edit controls you’ll see:
This table has no primary key, so its rows can’t be edited or deleted. Add one to enable editing.
Click Add primary key next to it and Paige adds one for you, then reloads the table with editing switched on. This normally only comes up on a table created outside Paige — anything you make with New Table has a primary key from the start.

​
System tables

Three tables come with every project and are managed by Paige: your contacts, conversations, and messages. They carry a System badge, and selecting one shows a warning — for good reason. Two more tables live in the database but are deliberately kept out of this tab, because there’s a better place to read each one:
  • Execution logs — read them in Logs instead, which is built for them.
  • broadcast_recipients — the per-recipient send ledger a broadcast writes as it goes. Paige’s sender is updating it live, so hand-editing it would corrupt a broadcast’s counts. Per-recipient delivery status is shown in the Broadcasts tab: open a broadcast and every recipient is listed there with its status and, for failures, the reason.
Editing system tables by hand can break your bot in ways that are hard to trace. Your bot uses these rows to know who it’s talking to and where it got to in a conversation; changing them out from under it is like moving someone’s furniture in the dark. Read them freely — but leave the editing to your bot unless you know exactly why you’re there.

​
Tables filled by a connected website

If you’ve connected a website in Tools → Connectors, the tables that sync fills up appear here too, marked with a Synced badge. You can open them and read everything that came across — that’s the quickest way to check your import actually worked. They’re view-only. There’s no Add Row, no Clear, no Drop Table and no cell editing, because Paige rewrites those tables on every sync and anything you typed would be replaced without warning. Change the content where it lives — in your website — and it updates here on the next sync. Records your site has deleted are hidden by default, so the row count matches what your bot actually sees. You can still download a synced table like any other, and the download follows the same rule — deleted records are left out of the file too, whether you pick current view or full table. If you do want to see them, filter the table on the deleted column first; the download then keeps whatever that filter shows.

​
Downloading a table

Click Download on any table and pick CSV, Excel, or JSON. The switch inside the dropdown decides how much you get:
  • Full table (the default) — every row, ignoring whatever filter you have on screen.
  • Current view — only the rows matching your filter, in the order you’re looking at them.
The file is named after the table and the date — bookings_2026-07-17.csv. Large tables are prepared in the background and download on their own when they’re ready, so you don’t need to wait around on the page. While one is being prepared the button shows Preparing, then Downloading — and you can leave the table and come back without losing it. One download at a time per project. Ask for a second while the first is still being prepared and Paige attaches you to the one already running rather than starting another; you get the same file when it’s ready.
Very large tables. There’s a limit on how big one download can be — not a row count, but the size of the finished file, because a table with a lot of long text or attachments can be enormous even with relatively few rows.If your table is over it, Paige tells you rather than handing you a half-finished file. Narrow it down with a filter and use current view instead of full table, or export it in a few passes. Very slow exports are given up on after about ten minutes for the same reason; you’ll see Export failed and can try again on a smaller slice.

​
The SQL editor

Click SQL in the top-right for a query box. This is the tool for questions the browser can’t answer — “how many bookings came in per day last week”, “which contacts never finished the signup flow”.
It runs against whichever schema the Preview/Production toggle is on, and the badge above the editor tells you which. Results show up to 500 rows, though the true count is always reported. SQL is a switch, not a one-way door: click it again to leave the editor and land back exactly where you were — the table you were looking at, or the table list if you came from there. Your query and the Write setting are kept, so you can pop out to check a table and come straight back to carry on.
Two things do send you back to the table list instead: switching between Preview and Production, and dropping a table. In both cases the table you were on may not exist any more. Switching schema also turns Write back off, so you can’t carry write access from Preview into Production without meaning to.

​
Read-only by default

The editor won’t change anything until you turn on the Write toggle. Try an UPDATE without it and you’ll be told to enable Write rather than have it run. With Write on, an amber banner appears and you can run anything — INSERT, UPDATE, DELETE, and schema changes, including on the system tables the point-and-click view protects.
Write mode has no undo and no confirmation step. A DELETE without a WHERE clause runs the instant you click Run, against real customer data if you’re on Production. Get in the habit of writing the SELECT first, checking the rows it returns, and only then turning it into an UPDATE or DELETE.
You rarely need this to be your first stop. Ask the Code agent in plain language — “how many bookings did we get last week?” — and it will query the database and answer. The SQL editor is for when you want to see the query, or run something the agent shouldn’t be guessing at.