MySQL + Go Fig
Integrate MySQL databases with Go Fig for unified financial data and reporting.
MySQL sits under a huge share of production applications, from e-commerce storefronts to booking systems to internal tools. For finance teams, that means MySQL is often where the real, transactional source of revenue and operational activity lives, before anything reaches QuickBooks or NetSuite. Go Fig connects MySQL as a first-class node in the Financial Intelligence Graph with binary-log-based CDC, so Celeste and AI financial analysts can join live order, subscription, and usage data to the GL without waiting on nightly exports. The connector reads from read replicas by preference, supports SSL, SSH tunnels, and VPC-private connectivity, and handles MySQL's type system quirks (UNSIGNED integers, DECIMAL precision, TINYINT-as-boolean, JSON columns, generated columns) without losing precision. Deployments on Amazon RDS, Aurora MySQL, Google Cloud SQL, Azure Database for MySQL, and self-hosted MySQL 5.7 / 8.x are all supported. For production databases, CDC via binlog replication is the default pattern so queries stay cheap and data stays within a few seconds of live.
Key facts
- Versions
- MySQL 5.7, 8.0, Aurora MySQL
- Sync mode
- Binlog CDC (row-format) + initial snapshot
- Networking
- SSH tunnel, VPC peering, PrivateLink
- Auth
- User/pass with SSL (TLS 1.2+)
- Replica-aware
- Prefers read replica if provided
What you can do with MySQL data in Go Fig
Live revenue from application DB
Pull orders, subscriptions, or transactions from MySQL with sub-minute freshness so revenue dashboards reflect the actual application state rather than last night's extract.
Operational-to-financial reconciliation
Reconcile what happened in the app (shipments, cancellations, refunds) against what posted to the GL, surfacing breakages before month-end close.
Cohort and unit-economics analysis
Join MySQL customer and order tables to billing and cost data in Go Fig for cohort retention, churn, and contribution-margin analysis at the segment level.
Data available from MySQL
Go Fig extracts and normalizes the following data from your MySQL account:
How to connect MySQL
Enable row-format binary logs
For CDC to work, MySQL must have binlog_format=ROW, binlog_row_image=FULL, and binlog_expire_logs_seconds set long enough to cover a worst-case sync outage (7 days is a safe default). On RDS/Aurora, this is a parameter-group change; on Cloud SQL, a flag on the instance. Confirm with SHOW VARIABLES LIKE 'binlog_format'.
Create a dedicated CDC user
CREATE USER 'fig_cdc'@'%' IDENTIFIED BY '...' REQUIRE SSL; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'fig_cdc'@'%'; and GRANT SELECT on the specific databases or tables Go Fig should sync. Point at a read replica if one exists so the primary is never touched by Go Fig reads.
Establish private networking
For production databases, avoid public access. Provide an SSH tunnel through a bastion (Go Fig generates a key you authorize), VPC peering to your account, or AWS PrivateLink for RDS/Aurora. Alternatively, allowlist Go Fig's published egress IPs in the security group, with SSL required.
Pick tables and snapshot strategy
In Go Fig, select databases and tables. The initial snapshot uses consistent reads (FLUSH TABLES WITH READ LOCK alternative via GTID-aware snapshotting when GTIDs are on) to capture a starting state, then CDC picks up from the binlog position. Large tables can be chunked by primary key for a non-blocking snapshot.
Authentication: Dedicated MySQL user with the minimum grants for CDC: REPLICATION CLIENT, REPLICATION SLAVE, and SELECT on the tables or databases to sync. TLS is required for internet-reachable instances. For private databases, use an SSH tunnel through a bastion, VPC peering, or AWS PrivateLink. IAM authentication on RDS and Aurora MySQL is supported where enabled.
Common Questions About MySQL Integration
Will binlog CDC load my production database?
Very little. CDC reads the binary log on disk, which MySQL is writing anyway for replication. Go Fig pulls the log asynchronously the same way a read replica does, so the steady-state overhead is negligible. The only heavier moment is the initial snapshot of large tables; that can be pointed at a read replica to keep primaries untouched.
What happens with schema changes (DDL) on a synced table?
Schema changes are detected from the binlog and Go Fig applies them to the downstream representation without breaking existing queries where possible (new columns are added; column type changes are flagged). Dropped columns are preserved in historical data. Destructive DDL like DROP TABLE is surfaced in the connector view for explicit handling.
How does Go Fig handle MySQL's type quirks (UNSIGNED, TINYINT(1), JSON)?
UNSIGNED integers keep their full range (BIGINT UNSIGNED is represented as DECIMAL to preserve the top bit). TINYINT(1) is treated as BOOLEAN by default, configurable per column. JSON columns are kept as JSON for downstream path queries, with the option to flatten specific keys into first-class columns. DECIMAL precision is preserved exactly.
Can Go Fig connect to Aurora MySQL and RDS MySQL?
Yes, both. On Aurora, point Go Fig at the reader endpoint so CDC reads don't touch the writer. On RDS, enable binary logging via the parameter group and set backup retention to at least 1 day (RDS requires backup retention > 0 for binlogs to be available). Cloud SQL for MySQL and Azure Database for MySQL are also supported with equivalent settings.
What if we can't enable binlog CDC?
Go Fig falls back to query-based incremental sync using an updated_at column or primary key high-watermark. This is less efficient (polls at 15-minute cadence rather than streaming) and doesn't capture deletes, but works when binlog access isn't available. For high-write tables, CDC is strongly recommended; for reference-data tables that change rarely, query-based is fine.
Ready to connect MySQL?
See how your MySQL data looks in Go Fig with a personalized demo.
Book a Demo