2 · Build a sample playground

No database handy? Create two schemas that differ on purpose — then you can compare them and watch FoxSchema find the drift. Run this on PostgreSQL or MySQL (works on both).

Schema A — the “source”

CREATE SCHEMA demo_a;

CREATE TABLE demo_a.customers (
  id            INT PRIMARY KEY,
  email         VARCHAR(200) NOT NULL,
  full_name     VARCHAR(120),
  signup_date   DATE,
  last_login_at TIMESTAMP          -- only in A
);

CREATE TABLE demo_a.orders (
  id          INT PRIMARY KEY,
  customer_id INT NOT NULL,
  total       DECIMAL(10,2) NOT NULL,
  status      VARCHAR(20)
);

CREATE INDEX idx_customers_email ON demo_a.customers (email);
CREATE INDEX idx_orders_customer ON demo_a.orders (customer_id);

INSERT INTO demo_a.customers (id, email, full_name, signup_date) VALUES
  (1, 'ada@example.com',   'Ada Lovelace',   '2024-01-15'),
  (2, 'linus@example.com', 'Linus Torvalds', '2024-02-02'),
  (3, 'grace@example.com', 'Grace Hopper',   '2024-03-30');

INSERT INTO demo_a.orders (id, customer_id, total, status) VALUES
  (1, 1,  99.00, 'paid'),
  (2, 2, 149.50, 'paid'),
  (3, 3,  20.00, 'refunded');

Schema B — the “target” (drifted)

CREATE SCHEMA demo_b;

CREATE TABLE demo_b.customers (
  id          INT PRIMARY KEY,
  email       VARCHAR(200) NOT NULL,
  full_name   VARCHAR(80),           -- narrower than A
  signup_date DATE,
  legacy_flag INT                    -- only in B
);

CREATE TABLE demo_b.orders (
  id          INT PRIMARY KEY,
  customer_id INT NOT NULL,
  total       DECIMAL(10,2) NOT NULL,
  status      VARCHAR(20)
);

CREATE TABLE demo_b.audit_log (      -- only in B
  id       INT PRIMARY KEY,
  action   VARCHAR(50),
  logged_at TIMESTAMP
);

-- note: idx_customers_email is missing here

INSERT INTO demo_b.customers (id, email, full_name, signup_date) VALUES
  (1, 'ada@example.com',   'Ada Lovelace',  '2024-01-15'),
  (2, 'linus@example.com', 'Linus T.',      '2024-02-02');   -- differs
  -- customer 3 missing entirely

3 · Connect your databases

1. Click Add connection.
2. Pick the type — PostgreSQL, MySQL, MariaDB, SQL Server, Azure SQL, Oracle, IBM Db2, SQLite, ClickHouse or Amazon Redshift.
3. Enter host, port, database, username and password (optionally a schema).
4. Hit Test, then save.

Passwords are encrypted at rest and are never sent back to the browser. Save one connection per environment you want to compare.

4 · Compare & migrate schemas

This is the core feature: point FoxSchema at a source and a target, and it shows every structural difference and writes the SQL to close the gap.

1. Open Schema Sync, choose source (demo_a) and target (demo_b).
2. Click Compare. Narrow the scope (tables only, views, routines…) with the scope filter.
3. Read the diff — click any object to drill into column, index, key and trigger changes.
4. Choose Generate migration to get runnable DDL in the target's dialect. Nothing is applied yet.
5. Review, then Deploy. A pre-migration snapshot is taken first, and the run is saved in History.

Comparing two different engines? FoxSchema is cross-dialect aware — equivalent types aren't flagged, and a readiness panel tells you up front what translates cleanly (tables, columns, keys, indexes) versus what needs a human (views, user-defined types, procedures).

Prefer the terminal? The same engine runs from the CLI:

foxschema compare --source demo_a --target demo_b
foxschema migrate --source demo_a --target demo_b

5 · SQL Editor

Run ad-hoc queries and inspect data — and, uniquely, run the same SQL against several servers at once to compare environments.

1. Click SQL Editor in the top toolbar.
2. Under Destinations, check one or more saved connections.
3. Type SQL, then Run. Select part of the text and it becomes Run selection.
4. Results appear below, grouped per connection — stacked or side-by-side.

Try this against both demo schemas:

SELECT id, email, full_name, signup_date
FROM customers
ORDER BY id;

Also in the Editor: tabs, a schema explorer with autocomplete, Index Management (fragmentation % + defragment), Clone Table (archive a huge table and recreate it empty), and Query files — import CSV/TSV, JSON or fixed-width text into a temporary SQLite workspace and query it like any other database.

6 · Database access & permissions

Inspect who can do what, and generate the GRANT/REVOKE SQL to fix it — without hand-writing dialect-specific permission syntax.

1. Open Build database access and pick a database connection.
2. Load the catalog to read users and roles from the server.
3. Choose a principal (a user or role), then set the desired access — per database, table, or column.
4. FoxSchema shows granted privileges today versus what you asked for, and writes the SQL to reconcile them.
5. Check the access report for high-risk findings — over-privileged accounts and similar.

Review the generated SQL before running it, exactly like a schema migration. Account and permission syntax is emitted per dialect.

Where to next

• • History — every applied migration, with its script, snapshot and per-object result.
• • Self-hosting guide — run the web app for your team with Docker, SSO and TLS.
• • Documentation · Install options · Blog