With Sequin, you can select which tables and columns you sync to your database. You can also rename and lock columns to make working with your data easier. We refer to this process of selecting and customizing which tables and columns you sync as "mapping" the data from the source to your database.
Selecting tables and columns
You can select which tables and columns you sync at anytime in the Select tables section of your sync:
You can change the tables and columns you're syncing at any time.
If you want to edit the columns syncing on a given table, click the ⚙️ Configure button to open the column mapping modal.
By default we'll sync all the columns from the source. You can pick which columns sync from the source to your database by flipping the switch on the left:
Internal columns, such as
_sync_updated_at can't be disabled as these are required fields for your sync to function.
You can lock column names to ensure that the column name in your database won't change even if the name in the upstream source changes. This can help insulate your queries and code from name changes.
To Lock or Unlock a column name, click on the 🔓 Lock icon right next to the Database name. The button will turn into solid black indicating that the column is locked:
Alternatively, you can batch Lock all columns or Unlock all columns using the buttons located at the top of the Select columns modal:
By default, all your column names are Unlocked. This means that as soon as a name change is detected in the source, the name of the column in your database will update.
A Locked column name will not change even if the name in the upstream source changes.
Sometimes the default names from your source aren't ideal for your database or code base. For these situations, you can rename the database column. When you rename a database column, the column name will also lock to ensure the name isn't overwritten.
To rename a column, click the ✏️ Edit icon right next to the Database name, then enter a valid name and save it.
In Postgres, valid names can't start with a number, have special characters or be a duplicate inside the table.
Sequin owns the tables
In Sequin's workflow, Sequin owns the tables and columns. Here are some things to keep in mind when working with your Sequin tables:
Don't modify tables or columns directly
It's important that you never modify your Sequin tables or columns directly. Any modifications to your Sequin tables or columns should happen via the Sequin console.
Don't add constraints
Additionally, avoid adding any constraints to your tables. These include things like foreign keys, non-null constraints, or unique indexes. Constraints added outside of Sequin can break Sequin's upsert and delete process, and break your sync.
Do add indexes
You're encouraged to add indexes to your Sequin tables according to your app's needs. Just make sure you don't add unique indexes (see the note about constraints below).
Be careful about modifying or dropping API fields
For some sources, schema changes can originate from the API. For example, Airtable, HubSpot, and Salesforce all offer the ability to customize your data model. In Airtable, you can add and remove tables and modify the columns in those tables. In HubSpot and Salesforce, you can add, remove, and modify custom objects.
Sequin polls the source API for schema changes. When we detect a schema change that impacts your sync, we'll automatically propagate that migration to your database. For example, if you drop a field from a custom object, we'll drop the corresponding column in your table.
We are exploring ways to give you more control over what Sequin does when a schema change originates from the API. Soon, you'll be able to manually approve each migration before it takes place.