Salesforce to PostgreSQL: How to Replicate Your Data
Move Salesforce into PostgreSQL with Airbyte. Why a successful sync can load fewer records, formula field drift, and exposing views to your application.
Moving Salesforce into PostgreSQL puts CRM records where an application or an internal tool can query them. A customer portal, an onboarding workflow or an admin panel that needs account and contact data is far simpler to build against a database than against the Salesforce API with its own limits.
This guide covers the managed path with Airbyte. One behaviour matters more than any setting: when the connector reaches your org's daily API limit it does not fail, it stops early and reports success, and whether that self-corrects depends entirely on the sync mode you chose.
Salesforce to PostgreSQL at a glance:
Why move data from Salesforce to PostgreSQL?
Two situations account for most of these pipelines.
The first is giving an application CRM context without giving it Salesforce credentials. A portal that needs to know a customer's plan or owner reads a local table rather than calling an API that has a daily budget shared with everything else in the business.
The second is joining CRM data to whatever already lives in that database. If you want multi-year analytics across a large org, a warehouse is the better destination, because Salesforce objects at that scale exceed what a relational destination comfortably holds.
What do you need before you start?
Two of these determine what your application will actually see:
A dedicated Salesforce integration user. The connector sees exactly what the authenticating user sees, so field-level security and sharing rules on that account decide what reaches your database. A pipeline built on somebody's personal login also changes contents when their permissions change.
A shortlist of objects and fields. Select what your application reads rather than everything available. Salesforce orgs accumulate custom objects, and syncing them all wastes API budget and fills a database that has a volume guideline to respect.
An agreed share of the daily API budget. Every connected application draws from the same org-wide pool, so exhausting it affects other people's integrations rather than only yours. Find out what else calls Salesforce before choosing a schedule.
A PostgreSQL user with write access. On the target schema, ideally one dedicated to synced data. If you already run a Postgres destination on an older connector version, read the migration guide before upgrading.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the PostgreSQL side before you begin.
How do you build a Salesforce to PostgreSQL pipeline in Airbyte?
Step 1: Scope the integration user
Create an account for the pipeline with deliberately chosen visibility, and write down what it can see. On a pipeline feeding an application that becomes part of your data model rather than an administrative detail, because a field the user cannot see is a field your product cannot show.
Step 2: Configure the Salesforce source
Click Sources in the left navigation, then New Source, and select Salesforce, following adding a source. Authenticate as your integration user and set a start date. Set the lookback window deliberately too, because Salesforce's API is eventually consistent and a record modified shortly before a sync may not be visible. The default is ten minutes.
Step 3: Configure the PostgreSQL destination
Click Destinations, then New Destination, and select Postgres, following adding a destination. From version 3.0.0 the Postgres destination uses Direct Load architecture, writing records straight to final tables with no intermediate raw tables, and adds its own metadata columns alongside your data.
Step 4: Use incremental append and deduped
Click Connections, then New connection, select your objects and choose incremental append and deduped as the sync mode. On any org of size this is not really a choice, for the reason in the next section. Deduplication also makes the lookback window free, since re-reading an overlapping period leaves no duplicate rows.
Then expose views to the consuming application rather than the raw tables, so Airbyte's metadata columns stay invisible and a future schema change can be absorbed in the view.
Why does a successful sync sometimes load fewer records?
When the connector reaches your org's daily API limit it does not fail. It stops where it is, reports the run as successful, and picks up from that position on the next run. That is sensible, because failing the whole sync would discard work already done.
The self-correction only works on incremental sync. Configure full refresh against a large org and every run truncates somewhere arbitrary, then starts from the beginning again next time, never reaching the end. That is why the sync mode above is stated as a requirement rather than a recommendation.
On a pipeline feeding an application the consequence is specific. A partially loaded table does not look broken, it looks like a customer record that is simply absent, and whoever reports it will describe a product bug rather than a pipeline one. Monitor row counts as well as sync status.
What changes in Salesforce without reaching your database?
Formula fields are the important case. The connector syncs the output of a formula rather than the formula itself, and editing that formula does not change any record's modification timestamp. Incremental sync therefore never re-reads those records, so your tables keep serving values calculated under the old formula indefinitely.
The fix is to reset the stream and run a historical backfill. The prevention is procedural: whoever administers Salesforce needs to know that changing a formula means telling the data team, in the same way a schema change would.
Deletions deserve a thought too. Records deleted in Salesforce can be retrieved from the recycle bin on streams that support it, arriving marked as deleted rather than vanishing. Filter on that marker in the views your application reads, or it will show records that no longer exist.
Frequently asked questions
Why did my sync succeed but load fewer records?
It hit your org's daily API limit. The connector stops there, reports success, and resumes next run. On incremental sync this is self-correcting, but monitor row counts because a partial table looks like missing data.
Why are some Salesforce fields missing?
The connector sees what the authenticating user sees, so field-level security and sharing rules on your integration user decide what reaches PostgreSQL.
I changed a formula field and nothing updated. Why?
Editing a formula does not change any record's modification timestamp, so incremental sync never re-reads them. Reset the stream and backfill.
Is PostgreSQL big enough for Salesforce data?
For a focused set of objects, comfortably. Airbyte recommends relational destinations for roughly 10GB or less, so a large org syncing everything would be better served by a warehouse.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want PostgreSQL views filtering deleted records and hiding metadata columns from your application.
Get your Salesforce data into PostgreSQL
Scope the integration user and document what it can see, keep the object list tight given the volume guidance, run incremental append and deduped so partial syncs resume, expose views rather than raw tables, and monitor row counts rather than only sync status.
Airbyte's connector catalog includes 600+ pre-built connectors, so CRM data can reach an application and a warehouse at once. For the analytical version, see Salesforce to Snowflake, and for search over the same records, Salesforce to Elasticsearch.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.