Zapier workflow to sync Airtable record deletions with PostgreSQL database

I’m trying to set up an automated workflow that removes records from my PostgreSQL database whenever I delete them from Airtable. I’ve been using Zapier to handle the integration between these two platforms.

The problem I’m running into is that Zapier seems to only offer triggers for when new records are created or when existing records get updated in Airtable. I can’t find any built-in trigger option that fires when a record gets deleted.

Has anyone found a workaround for this? Maybe there’s a different approach or some hidden setting I’m missing. I need the PostgreSQL table to stay in sync with my Airtable base, so when something gets removed from Airtable it should also disappear from the database automatically.

Any suggestions would be really helpful since this is blocking my current project setup.

You could try Airtable’s webhooks if you’re on Pro or higher. Set up a webhook that triggers when records get deleted and point it to a simple script or serverless function.

I did this last year - webhook hits an AWS Lambda that runs the DELETE query on PostgreSQL. Takes about 30 minutes once you figure it out.

No webhooks? Flip it around. Don’t try detecting Airtable deletions. Just add a timestamp field that updates when records change. Run periodic checks to flag PostgreSQL records that haven’t been touched in Airtable for X time.

Not perfect, but caught 99% of our deletions. The timestamp thing worked great since our team was already updating records regularly anyway.

Indeed, Zapier lacks native support for deletion triggers from Airtable, which can be frustrating. However, a practical workaround I’ve found is to create a scheduled Zap that runs either daily or hourly. This Zap should retrieve all current record IDs from Airtable and then cross-reference them with your PostgreSQL table. Any IDs present in PostgreSQL but not in Airtable can be removed accordingly. You may need to implement a Code step for the comparison, but this method has proven reliable for me. While it won’t provide real-time updates, it generally suffices. Just ensure that your API key has the necessary read permissions and be mindful of any rate limits.

I’ve had great success with soft deletes instead of actually removing records. Just add a status field to Airtable with “Active” and “Deleted” values. When you need to delete something, flip the status to “Deleted” - that’s it. Zapier’s update trigger catches this change and handles the real deletion in PostgreSQL. You get real-time sync without jumping through hoops, plus you’ve got an audit trail showing what got removed and when. Pro tip: filter out “Deleted” records in your Airtable views so they don’t mess up your interface.

zapier’s airtable triggers are kinda basic. i suggest you try make (was integromat) - its way better at catching deletions than zapier. or you could just write a quick script to compare record counts between the systems and alert when they dont match. not perfect, but it works if you want to skip webhooks or premium fees.

Polling beats fighting Zapier’s weird limits. Hit this same problem 6 months back on a client project. Ditched Zapier triggers and built a simple scheduled job that checks both systems every few minutes for orphaned PostgreSQL records. The trick? Store Airtable record IDs as a reference column in PostgreSQL when you first sync. My script grabs all active Airtable IDs, runs a NOT IN query against PostgreSQL to catch records that don’t exist upstream anymore, then auto-purges them. Run it every 10-15 minutes - sync delay’s fine and you’re not hammering the APIs. Costs almost nothing since it’s just two queries each cycle. Way more solid than webhooks that break when services crash or you hit rate limits.