Best answer

Salesforce -> PostgreSQL webapp integration, intermediate database

  • 16 February 2021
  • 1 reply



We’re evaluating Zapier to pass data back and forth between Salesforce and a custom

webapp backed by a PostgreSQL database.  The data flow would look like this:


Salesforce <=> Zapier <=> PostgreSQL webapp database (Flow A)


The data flows in both directions. 


But, the page “How to Get Started with PostgreSQL”

includes this text:

Note: all fields are stored encrypted in our database. Of course, we
have the encryption keys on hand but they are stored separately to minimize
risk. Nonetheless, we recommend not hooking a production database to
Zapier. Instead, set up an intermediary database to connect with Zapier
then dump data back to your main production database using some out-of-band


My reading of this is that we shouldn’t let Zapier talk to the webapp production database at all.

Rather, the data flow should look something like this:


Salesforce <=> Zapier <=> PostgreSQL intermediary database <=> PostgreSQL webapp database

(Flow B) 

In this case, Zapier would not be responsible for communication between the two Postgres



Unfortunately, we haven’t able to get 100% clarification on this issue from support or in the documentation.  We still have these questions:

  1. Which is recommended, Flow A or Flow B?  Or in other words, should Zapier only talk to an intermediary database, or can it talk directly to a production database?
  2. If Flow B is recommended, what are the risks of talking directly to the production database?
  3. Is there any existing documentation that further explains why an intermediate database is necessary?
  4. If Flow B is recommended, is Postgres replication considered an acceptable out-of-band process?

Thank you,




Best answer by Danvers 19 February 2021, 13:47

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

1 reply

Userlevel 7
Badge +12

Hi @alaser-te!


I’m not an expert on PostgreSQL but my understanding is that the purpose of the intermediate database is a layer of safety, so you’re not directly exposing your database to Zapier. 

In this case, Zapier would not be responsible for communication between the two Postgres databases.

That’s exactly it - you have a separate database that acts as a go-between so that Zapier doesn’t have direct access to your production database. 

I don’t know enough to comment on why this is the best solution, perhaps someone else here will have some more insight. If not it might be worth asking PostgreSQL if they can explain the risk. 


I hope that helps!