Save a database connection

Save each database once and reuse it everywhere: Compare, the Editor and Utilities.

Open it: Creds on the left rail

How to use it

1. Click Creds on the left rail.
2. Pick the database type. Saved connections are grouped by type, and you can search them by name.
3. Fill in host, port, database, username and password. SQLite and DuckDB use a file path instead: choose it with Browse….
4. Click Load Schema to check the connection and list its schemas, then Save Credential. Passwords are encrypted and never sent back to your browser.

Compare two databases

FoxSchema reads both schemas and builds one diff covering tables, columns, keys, indexes, views, functions and more.

Open it: Compare on the left rail

How to use it

1. Open Compare.
2. Choose an Original Server connection (where you compare from) and a Target connection (where you compare to).
3. Click Compare.
4. Use the scope filter to narrow what is read, for example tables only, or views and functions.

Read the diff

Every object is marked Added, Modified, Removed or Unchanged, so you see what a migration would do before you run anything.

How to use it

1. Check the summary at the top: Added (green) exists in the Original but not the Target, Modified (yellow) differs, Removed (red) exists only in the Target, and Unchanged is identical.
2. Click an object to see the exact column, index, foreign-key and trigger differences.
3. Use the search box to jump straight to a name.

Generate and deploy a migration

Turn the diff into SQL in the Target’s own dialect, review it, then apply it, or copy it and run it yourself.

How to use it

1. From the diff, tick the objects you want under Deploy to Target (the checkbox at the top ticks them all), then open Migration SQL.
2. Review the SQL. Nothing has been applied yet.
3. Click Execute Sync Script. If the plan drops anything, tick the acknowledgement above the SQL first. Confirm in the dialog, and FoxSchema takes a pre-migration snapshot first.
4. Optional: turn on No drops to leave every drop out of the plan, or Skip failures to continue past any single object that fails instead of rolling back the whole run. The result says “completed with failures” and lists what was skipped.

Execute safety checks

Execute refuses a plan that would leave the Target inconsistent or that you have not acknowledged, so a risky deploy cannot happen by accident.

What it checks

• A foreign key that would point at a table missing from the Target, or a type change that narrows (for example varchar(100) to varchar(20)): Execute opens a review instead of deploying. Include the missing table, drop the foreign key, or acknowledge the narrowing.
• A drop that would break a dependent object, a destructive drop, or a MySQL CREATE FUNCTION where the binary-log privilege is a risk: Execute stays disabled until you resolve or acknowledge it.
• Execute is also disabled when your role cannot migrate, nothing is selected, the Target is disconnected, or a required Git commit is missing.

Commit a migration to Git

Keep a reviewable, replayable record: commit the migration as a plain SQL file, then run it from that exact commit.

Available once an admin has added a Git repository under Access control → Git

How to use it

1. In the migration view, choose Commit to Git next to Execute.
2. Choose the repository and a branch, or New branch…, which starts from the repository’s default branch.
3. Write a note. It becomes the commit message, so say what the migration does and why.
4. Review the file FoxSchema will add (for example migrations/20261002-153012__your-note.sql). It is plain SQL anyone can read and run, and passwords in account statements are replaced with <password>.
5. Click Commit, or Commit & push to send it to the remote for review. Execute then reads “Execute committed” and runs from that commit.

Run SQL on one or many servers

Check several Destinations and the same SQL runs against every one, which is handy for comparing environments.

Open it: Editor on the left rail

How to use it

1. Open Editor.
2. Under Destinations, check one or more saved connections.
3. Type SQL. Several statements are fine, but Run executes only the statement your cursor is in.
4. Click Run. Results appear below, grouped by connection, stacked or side by side.
5. Select any SQL and Run becomes Run selection: only that text executes.

Schema explorer and autocomplete

Browse objects without leaving the editor, and get completions from the live schema.

How to use it

1. Browse tables and other objects in the explorer on the left. Click a name to insert it at the cursor.
2. Type a schema name and a dot (for example demo_a.) to list that schema’s tables. table. and alias. suggest columns.
3. In FROM and JOIN, the inserted name comes with an alias so you can qualify columns with the short name.
4. Open Edit table to see each index and its fragmentation.

Data Peek and row editing

See a table’s rows without writing a query, follow foreign keys, and add, edit or clone a row from a form.

How to use it

1. Hold Cmd (macOS) or Ctrl (Windows and Linux) and click a table, view or MQT in the explorer.
2. In results, foreign-key cells are underlined. Click one to open the related parent rows. Panels stack as you follow more links, and Esc closes.
3. Edit WHERE, ORDER BY and LIMIT. Filters apply when you edit, leave the field, or press Enter.
4. With the right permissions, use Add, Edit or Clone row. The sparkles button generates realistic sample values, and Preview shows the SQL (and a diff for edits) before you Save.

Compare data across servers

Line up the same query from two or more servers by key and see exactly which rows differ.

How to use it

1. Switch the results layout to Side-by-side and check two or more Destinations.
2. Turn on Compare data. It is off by default so grids stay plain.
3. Rows line up by key columns (primary keys, or the Keys you check), so matching IDs share a row.
4. Read the colors: amber is modified, rose is only in the original, emerald is extra or only in the destination.
5. Click Compare 2,000 rows to re-read both sides in key order. Every row in that window is classified, and you can filter by All, Changed, Only in source, Only in target, Unresolved or Matching.

Data migrate

Apply the differences you found, adding, editing or deleting rows on the destination, with a safety net and a record of what changed.

How to use it

1. With Compare data on, Data migrate appears below it.
2. Add, Edit and Delete are all ticked by default. Untick any you do not want: Delete removes rows from the destination.
3. Use the Sync column to include or exclude individual rows. Sync all re-checks every differing row.
4. Pick your safety options: Transaction (all-or-nothing when Stop is on), and Stop on error or Continue on error.
5. Click Apply. With Safe mode on, confirm the prompt (for example “Apply 4 ops”). Progress lists each row, FoxSchema snapshots the affected destination rows, and the run is recorded under Data migrate history.

Variables and secrets

Capture a value once and reuse it in later statements, even per server.

How to use it

1. Put -- @set name immediately above the SELECT whose result you want, then use ${{name}} in later statements.
2. For a column, write -- @set ids = column id and use ${{ids}}. For a table, write -- @set t = table and use ${{t.id}}.
3. You can also add variables in the Variables sidebar, or right-click a result cell, column header or empty grid.
4. Mark a variable secret to mask it. Secret values live only for the session, so re-enter them after a reload.

-- @set orderid
SELECT MAX(id) FROM orders;

SELECT * FROM order_items WHERE order_id = ${{orderid}};

Code cells (JavaScript and Node)

Mix SQL with a little JavaScript to transform results, call an API or generate test data, all in the same buffer.

How to use it

1. Fence a cell with -- @js … -- @end (runs in your browser) or -- @node … -- @end (runs on the FoxSchema server). TypeScript versions are @ts and @nodets.
2. The cell receives last (the previous statement’s grid) and vars (your variables). You must return either { columns, rows } or an array of plain objects. Tick the cell and the statement before it on the run rail so they run together; otherwise last is empty.
3. Import lodash, date-fns or @faker-js/faker at the top of the cell.
4. In Node cells, run SQL with the sql tagged template. Values become bind parameters, so they never turn into SQL text.

SELECT id, email FROM user;

-- @js
import _ from 'lodash';
return _.map(last.rows, (r) => ({ id: r[0], doubled: Number(r[0]) * 2 }));
-- @end

Tabs, bookmarks and results

Keep your work organised and your results manageable.

How to use it

1. Open several tabs and rename one with a double-click. Your SQL text is remembered locally; result grids are not.
2. Save reusable snippets as Bookmarks from the sidebar.
3. Click Format to pretty-print the buffer, and Clear to remove the active tab’s results.
4. Set Rows/page (200 by default) and use Next and Prev. Visited pages stay cached, so going back does not query the server again.

Safe mode and One transaction

Guard rails for running writes: confirm risky statements, and make a batch all-or-nothing.

How to use it

1. Safe mode: when on, UPDATE, DELETE, MERGE, upserts that can overwrite rows, and DDL need an extra confirmation. A plain INSERT does not.
2. On the run rail, a statement’s number turns amber for a write Run will ask you to confirm, and red with ! for an UPDATE or DELETE with no WHERE.
3. One transaction: when on, every statement in that Run is one transaction per destination. A failure rolls the batch back and later statements do not run.
4. Engines that auto-commit DDL (MySQL, MariaDB, TiDB, Oracle, CockroachDB) cannot undo DDL that already ran. Redis, MongoDB and ClickHouse cannot roll back at all, so a multi-statement Run with One transaction is refused there.

Index Management

See which indexes are fragmented and clean them up in batches.

Open it: Utils → Index Management

How to use it

1. Pick a connection and click Load indexes. Indexes are grouped by table.
2. Filter by name or by a minimum fragmentation %.
3. Click Fetch fragmentation to measure many indexes in one batch.
4. Defragment selected indexes, or all the filtered rows.

Clone Table

Archive a huge table and recreate an empty one with the same name and columns, so applications keep working.

Open it: Utils → Clone Table

How to use it

1. Click Load tables and pick the table. The archive is named name_1, the next free name_N, or a number you choose.
2. Toggle Keep indexes and Foreign keys (auto) for the new table.
3. Review the SQL preview, then Insert SQL into the Editor or click Apply clone.

Rename Column

Rename a column, change its type, or both, the safe way, with the impact shown first.

Open it: Utils → Rename Column

How to use it

1. Pick a table and column, then a new name and/or type. Types already used on this connection are suggested.
2. Review what it touches: indexes, unique constraints, outbound foreign keys, triggers, functions, procedures, and views that may mention the column (a text match).
3. A rename alone is one instant statement. A type change runs in three parts: add a nullable column, copy rows in batches with progress, then move constraints, triggers and the description and drop the old column.
4. Copy or Run each part, or choose Execute all. Open in editor sends the whole script to a new tab.

Backup and Restore

FoxSchema writes the backup and restore commands for your connection and tells you where they run.

Open it: Utils → Backup & Restore

How to use it

1. Pick a connection. The amber banner says where the command runs: on your machine, on the database server, or in the cloud.
2. Choose folder, format, scope and compression.
3. Copy the shell command, or use Open in SQL Editor for SQL-based backups.
4. For SQL Server, CockroachDB, ClickHouse and DuckDB, Run backup now runs it after a confirmation that names the file and connection. List backups on this server shows existing ones, newest first.

Server insights

Quick health checks: Connection Pool, User Connections, System Info, and Table and Index Size.

Open it: Utils → Insights

How to use it

1. Pick a connection and choose a tool under Insights.
2. Read the figures. They are estimated where the engine has no physical measure.
3. Click Refresh to update them.

SQL Tracer

Watch the statements hitting a connection, as they run.

Open it: Utils → SQL Tracer

How to use it

1. Pick a connection and open SQL Tracer. It needs the SQL Tracer permission (Owner and Admin by default) because a trace shows other people’s SQL.
2. Choose Fox activity (every statement run from FoxSchema on this saved connection, with time, rows and any error; works on every engine) or Live (the engine’s own session list, read about once a second; not on SQLite or DuckDB).
3. Click a row for the full text and Open in editor.
4. Press Stop when you are done.

Query files

Query a CSV, JSON or fixed-width file with SQL, or load it into a database table.

Open it: Utils → Query files

How to use it

1. Open Query files and add a file: CSV or TSV (comma, tab, semicolon, pipe or custom delimiter), JSON (an array or NDJSON), or fixed-width text.
2. Pick a destination: a new temporary SQLite workspace (the default; add more files later so several tables share it) or Import into saved credential.
3. Click Import & open: FoxSchema opens the Editor on the new file with a ready-made SELECT.

DB users and grants

Look up database users and what they can do, from the same catalog as the Access workspace.

Open it: Utils → DB users & grants

How to use it

1. Pick a connection and open DB users & grants.
2. Browse the users, roles and their privileges.
3. Changes (GRANT and REVOKE) need the Grant privileges permission.

Take and browse snapshots

Track versions of one database over time, and see what changed between them.

Open it: Snapshots on the left rail

How to use it

1. Pick a saved connection and click Capture (a brand-new history offers Take first snapshot instead). Snapshot again after a live change. Applying a Compare migration also records a version.
2. The version graph stays on screen while it reloads. Use Graph to hide it.
3. Original and Target work like Compare: Original is a version, and Target is the live database or another version.
4. Click Compare to compare the two versions. It is a preview: nothing is written to the live database until you press Revert or Update.

Revert or update to a version

Roll a live database back to an earlier version, or bring it forward, with a plan you review first.

How to use it

1. Pick the versions to compare, then tick the objects to change (or Select all). Nothing ticked means nothing runs.
2. Review the plan. A plan that would destroy data needs an extra confirmation, and a blocked plan is refused.
3. Click Revert, which rolls back, or Update, which appears when the plan only adds because the database has fallen behind.
4. FoxSchema snapshots first, then appends a new version. It never rewrites the version you picked.

Force migrate to another database

Apply a stored version to a different database.

How to use it

1. Click Force migrate… and pick its own version and target. These are separate from whatever the graph is showing.
2. Confirm “this is not the history’s database”.
3. If the plan destroys data, confirm that separately. Agreeing to data loss is not agreeing to target another database.

Migration history (Applies)

Every Schema Compare migration you apply is recorded, with its status, target, exact script, pre-migration snapshot and per-object results.

Open it: Applies at the bottom of the left rail

How to use it

1. Open Applies and pick a run.
2. Read its status, target and the exact script that ran.
3. Review per-object results, including any failures that were skipped.

Migrations from your team (Git)

See which committed migrations have run against the database you are connected to, and run the ones that have not.

How to use it

1. In Applies, open Git and pick a repository’s branch.
2. Fetch gets the remote’s branches and shows how far behind or ahead you are. Pull brings the branch up to date. If the same file changed on both sides, FoxSchema stops and changes nothing.
3. Each migration is marked Applied, or Incoming when it has not run on this target yet. Review shows the file.
4. Click Run on an incoming migration to apply it from its commit, with the same confirmation and progress as Execute. Push sends your own commits; if the remote moved on, pull first.