Skip to main content
This guide covers both directions between Airtable and MySQL. It uses an explicit destination contract, a published SQL model, and a stable Upsert key for repeatable runs.
Names, emails, companies, and rows shown in code blocks are synthetic fixtures. They are examples, not customer records or live customer activity.

Validated connector routes

The following routes were exercised through the MantrixFlow browser workflow with real source previews and destination verification: This is a functional verification matrix, not a throughput benchmark. Validate your own field types, permissions, row volume, and rate-limit behavior before a production rollout.

Shared preparation

Create and test these reusable connections:
  1. An Airtable source connection with schema and record read access.
  2. An Airtable destination connection with schema read plus record read and write access. One token can be reused for both roles when your security policy permits all required scopes and bases.
  3. A MySQL source connection with read access to the source database.
  4. A MySQL destination connection with write access to the destination database and its existing tables.
See Airtable source, Airtable destination, MySQL source, and MySQL destination for least-privilege setup.

Prepare reusable test data

Airtable source table

Create an Airtable table named Customers with these fields: Enter at least three records. Keep External ID unique and populated.

Airtable destination table

Create a separate table named Pipeline Sink with these writable fields: Do not use a formula or lookup as External ID; merge fields must be writable.

MySQL source table

MySQL destination table

Airtable to MySQL

1. Create the pipeline

  1. Open Data Pipelines and click New Pipeline.
  2. Name it Airtable Customers to MySQL.
  3. Choose the Airtable source connection and create the pipeline.

2. Configure Airtable source

  1. Open Source.
  2. Click Load bases and select the base containing Customers.
  3. Select the Customers table.
  4. Preview rows and confirm _airtable_record_id, External ID, Name, and Email appear.
  5. Keep Full table mode and click Save stream settings.

3. Configure MySQL destination

  1. Open Destinations, click Add destination, choose the MySQL connection, set the target database to analytics, and save.
  2. Open Transformations, select the MySQL destination, and create a model using the Airtable source stream.
  3. Use this SQL, replacing the staging relation with the exact lowercase value shown in the editor:
  1. Save draft, Validate draft, Preview output, and Publish revision.
  2. Return to the destination editor.
  3. Under Published output targets, set analytics.airtable_customers and select external_id as the Upsert key.
  4. Create/verify the table if needed, then save the destination.

4. Run and verify

Validate the pipeline from Overview, click Run all, and wait for Succeeded in Runs. Then run:
Edit one Airtable name and rerun. The row should update without increasing the count.

MySQL to Airtable

1. Create the pipeline

  1. Create a pipeline named MySQL Customers to Airtable.
  2. Choose the MySQL source connection.

2. Configure MySQL source

  1. Open Source and click Discover catalog.
  2. Enable source_app.customers.
  3. Preview the three test rows.
  4. Use Full table for the first run and click Save stream settings.

3. Add the destination and publish the model

Open Destinations, add and save the Airtable destination connection. Then open Transformations, select it, create a transformation using the MySQL stream, and use:
Save the draft, validate, preview, and publish the revision before configuring the Airtable fields.

4. Map Airtable destination fields

  1. Return to the Airtable destination editor.
  2. Click Load bases, select the destination base, and choose Pipeline Sink.
  3. Under Published output targets, map fields:
  1. Save the destination, validate from Overview, and click Run all.

5. Verify Upsert

Open Pipeline Sink in Airtable and filter External ID by mysql-. Confirm all three records and their mapped values. Update mysql-002 in MySQL, rerun, and confirm Airtable updates the same record rather than creating a duplicate.

Airtable to Airtable

Use separate source and destination tables, even when they are in the same base. Configure Customers as the source and Pipeline Sink as the destination.
Map external_id to External ID and select it as the merge key. The prefix prevents collisions with IDs from MySQL, Stripe, HubSpot, or other pipelines sharing the same sink table.
Do not target the same Airtable table used as the source. A self-feeding Full Table pipeline can continually expand its own input or overwrite records in ways that are difficult to audit.

Run checklist

Before each run, confirm:
  • both connections still pass their connection tests;
  • source discovery shows the expected table;
  • preview returns representative rows;
  • the published SQL model uses the staging name shown by the transformation editor;
  • the database table or Airtable table already exists;
  • every destination column has a compatible type or field mapping;
  • the Upsert key is unique and populated for every output row; and
  • the Runs tab reports failed rows = 0.

Common errors

Production rollout

After a successful Full Table validation:
  1. Record the source count and destination count.
  2. Rerun unchanged input and confirm no duplicates.
  3. Update a source record and confirm an in-place destination update.
  4. Review the token and database grants for least privilege.
  5. Set an operational schedule only after the manual run is stable.
  6. Monitor Runs for row-count changes, retries, and mapping failures.