Documentation & Help
Supported database pairs, known limitations, and migration guides
Getting Started
- 1Create a new project from the sidebar
- 2Enter your source database connection details (host, port, username, password, database name)
- 3Enter your target database connection details
- 4Use the 'Test Connection' button to verify connectivity
- 5Click 'Create Project' to begin
Running a Migration
- 1Open your project from the Dashboard
- 2Click 'Analyze' to scan the source schema — this detects tables, columns, indexes, FKs, and potential data loss
- 3Review the Schema tab for type mappings, data loss warnings, and table statistics
- 4Click 'Migrate' to start data transfer — progress streams in real-time via Server-Sent Events (SSE)
- 5After migration, click 'Validate' to compare row counts and data integrity
- 6Export a report from the Report tab (HTML or JSON)
Understanding Data Loss Warnings
- 1After analysis, check the 'Data Loss Analysis' table in the Schema tab
- 2Risk levels: HIGH = potential data corruption, MEDIUM = precision/constraint loss, LOW = format change only
- 3Common warnings: BIGINT→INT (truncation), ENUM→TEXT (constraint loss), DATETIME→TIMESTAMP (timezone handling)
- 4Review each warning and decide if the mapping is acceptable for your use case
- 5Use the Query Playground to spot-check critical data after migration
Using the Query Playground
- 1Navigate to 'Query Playground' from the sidebar
- 2Select a project and choose source or target database
- 3Write a read-only SQL query (SELECT, SHOW, DESCRIBE, EXPLAIN)
- 4Press Ctrl+Enter or click 'Run Query' to execute
- 5Results are displayed in a table format, capped at 500 rows
- 6Use this to verify data integrity after migration
Going Live with Cutover
- 1Finish a migration with zero-downtime CDC running (Incremental Sync → Start)
- 2Open the project's Cutover tool — the readiness check shows a go/no-go per precondition
- 3Put your application into read-only / maintenance so the source stops taking writes
- 4Start the cutover: it drains the change stream (CDC lag → 0, no new events for the quiet window)
- 5Verification re-compares every table (row counts + checksums) — the flip only happens if the target provably equals the source
- 6After the flip the target is authoritative and CDC stops — point your application at the target
- 7You can abort at any stage before the flip; CDC keeps running and nothing changes
Watching for Drift with Reconciliation Monitors
- 1Open Reconcile from the sidebar and connect the two data sources you want compared
- 2Create a monitor: pick source, target, check interval (15 min – 24 h) and depth (sampled or exact)
- 3Every interval, all common tables are compared — row counts plus type-aware checksums
- 4The moment a pair drifts apart you get a reconciliation_divergence webhook and an alert entry
- 5Alerts fire on the transition into divergence only — a persistent mismatch won't re-alert every interval
- 6Use 'Run now' for an immediate check after a fix
Reusable Masking Policies
- 1Configure masking rules on any project (Data Masking tool), then 'Save current as policy…'
- 2Or click 'Suggest from PII scan' to seed rules from the server-side PII detection (regex + Luhn validation on sampled rows)
- 3Apply a saved policy to any other project in one click — rules merge, the policy wins on conflicts
- 4Strategies: hash, redact, fake, nullify, partial — previewed on live sample rows before you commit
Data Console: Browsing a Database Safely
- 1Open Data Console from the product switcher and connect a data source (read-only credentials recommended)
- 2The schema loads automatically — browse tables, filter and search rows, follow foreign keys with one click
- 3Run the sensitivity scan so PII columns are flagged and masked for anyone without an unmask grant
- 4Share the source with teammates read-only; grant unmask rights per column only where justified
- 5Use Access Review for a CSV report of who can browse and who can unmask, across every source
- 6Need staging data? Generate a masked, FK-intact test-data copy instead of sharing production
Agent Gateway: Connecting an AI Agent
- 1Create a gateway: connect the database — schema is introspected and scanned for PII automatically
- 2Set the policy: allowed tables, denied columns, PII masking, row cap, rate limit, and usage budgets (per token and gateway-wide)
- 3Optionally define named views — curated slices (chosen columns, forced filters, row cap) agents query by name
- 4Issue a scoped agt_ token; optionally bind it to your server's IPs and set an expiry
- 5Point your agent at the MCP endpoint (or REST) with the token — it gets list_tables, query_table, query_view, aggregate_table
- 6Watch the Activity tab: every query is audited, and Replay shows exactly what the agent saw
- 7Writes: define named actions; agents propose, you approve in-app or from Slack, with one-click undo
Dataset Version Control: Branch, Diff, and Merge a Table
- 1Open a Data Console source (or an Agent Gateway) and click 'Version control' — pick the table you want history for
- 2Commit a snapshot: it's hashed row-by-row and stored — unchanged rows cost nothing extra, only what actually changed is written
- 3Branch off any point in the history to try changes in isolation, without touching the branch others rely on
- 4Diff any two commits to see exactly which rows were added, removed, or changed, with before/after values for a sample
- 5Merge a branch back: rows only one side touched apply automatically; rows both sides changed differently are flagged as conflicts, not silently overwritten
- 6Checkout any past commit to view the table exactly as it looked then — read-only, nothing is written back to the live table
- 7On an Agent Gateway, every approved agent write auto-commits onto an 'agent-writes' branch — so an agent's change is diffable and revertible through full history, not just a single-action undo
Need more help? Use the above or contact your workspace administrator for support.