Destination guide · MySQL
Let the MySQL application database see the customer context Salesforce owns.
For a MySQL-backed application, the goal is the same as it is for Postgres: make selected CRM records local, queryable, and recoverable—without teaching every service to manage Salesforce APIs and rate limits.
Scope the mirror around a product workflow.
MySQL can already be the database your application uses for user accounts, subscriptions, support state, or partner data. The cleanest CRM mirror brings only the Salesforce fields that enrich those workflows. Start with a simple question: what customer question should the application answer without issuing a remote CRM query?
That often produces a focused first mapping: Account and Contact for account context; Opportunity and a custom entitlement object for account status; Case for customer support. Document which system owns each field and whether a deleted Salesforce record becomes a soft-deleted local row.
Create tables that are safe to revisit.
Use the Salesforce record ID as a unique local key. It lets the sync repeat a batch or reprocess an event without adding duplicates. Keep source metadata alongside business columns: the source modification time, local sync time, and a deletion marker make investigation and reconciliation much easier.
Your application should have a stable table contract. A worker can use staging internally, but the tables application code reads should not disappear and reappear during a routine backfill.
Source ID: unique index on the Salesforce record identifier.
Relationships: retain parent record IDs so local joins remain possible.
Types: validate date, currency, null, and picklist mappings explicitly.
Indexes: add them for your product queries, not just the ingestion worker.
Backfill once, then subscribe to changes.
Use a complete first backfill to establish the local starting point. Then subscribe to Salesforce Change Data Capture for the selected objects and apply each change with an idempotent upsert or deletion update. The database transaction and the event replay checkpoint belong together: if the local write fails, the checkpoint should not advance.
CDC is a latency path, not a complete operational policy. Build a scheduled reconciliation for the selected objects and decide what happens when a record’s permissions, field mapping, or source schema changes.
Operate the mirror like a small production service.
Track event lag, successful writes, source API errors, failed records, and reconciliation differences. Alert on meaningful drift rather than every transient retry. For an existing MySQL estate, validate connection limits and lock behavior during a backfill; an integration should not contend with your customer-facing workload.
If the MySQL database is private, a customer-network worker is the natural model. It can initiate outbound connectivity to Salesforce and the connector control plane while retaining database access inside your own network boundary.
Implementation checklist
Map one workflow first: prove the tables solve a real application query before expanding object coverage.
Load safely: use batched backfill writes that respect connection and lock budgets.
Make events repeatable: source ID plus idempotent writes and post-commit checkpointing.
Reconcile: compare a useful subset on a repeatable schedule and surface drift to an owner.
Already running on MySQL?
We can help turn the customer data your app needs into a scoped, dependable local mirror.