Salesforce to Postgres integration for a live queryable copy of your CRM
The Salesforce to Postgres integration from Adapters replicates accounts, contacts, opportunities, and custom objects from the Salesforce API into Postgres tables on an incremental schedule, so your apps, internal tools, and reports read live CRM data with plain SQL instead of burning Salesforce API calls on every query. Field mapping is no-code.
No credit card required.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Last updated September 2026
What running Salesforce to Postgres by hand costs you
- Querying Salesforce live through the REST or SOAP API counts against a daily call limit, so an app or dashboard that reads it directly slows down or hits the cap under load.
- Building a local Postgres copy by hand means paging the API, tracking the SystemModstamp watermark, and upserting on the Salesforce Id without doubling rows, which is fiddly to keep correct.
- Analysts want CRM data joined to product and billing tables in one Postgres database, not a nightly CSV export that is already stale by the time the report runs.
The field mapping, out of the box
These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.
Input / SALESFORCE
Output / POSTGRES
Transforms included
Incremental loads page the Salesforce API using the SystemModstamp watermark so each run pulls only new and changed records; the 18-character Salesforce Id becomes the Postgres primary key, currency fields cast to NUMERIC, ISO 8601 timestamps become timestamptz in UTC, and writes upsert on the Id so a retry updates in place instead of doubling rows.
Salesforce to Postgres: the API ceilings that decide your schedule, and the deletes you will miss
Replicating Salesforce into your own database is mostly an exercise in respecting somebody else's rate limits. Salesforce publishes hard daily ceilings that decide how often you can sync, a separate bulk path for the backfill, and a watermark field that is not the one most people reach for. Below: the numbers that shape the design, the field that keeps incremental runs honest, and why a watermark query alone will slowly fill your Postgres tables with records that no longer exist. Salesforce developer limits cheatsheet read 12 August 2026.
Your daily API call ceiling sets the sync frequency
This is the number to look up before designing anything, because it is per org per 24 hours and it is shared with every other integration you run. Salesforce allocates 15,000 calls a day on Developer Edition, 100,000 plus 1,000 per licensed user on Enterprise and Professional, 100,000 plus 5,000 per license on Unlimited, and 5,000,000 on a Full Sandbox. A 50 user Enterprise org therefore has 150,000 calls, which sounds generous until you divide it across a middleware tool, a marketing platform, a support integration and your own sync. Work out the budget your pipeline is allowed to spend, then pick the schedule, rather than picking a five minute schedule and discovering the ceiling when an unrelated integration starts failing.
Use Bulk API 2.0 for the backfill, REST for the increments
The initial load and the ongoing sync want different APIs. Bulk API 2.0 exists for volume and its ingest ceiling is 150,000,000 records per rolling 24 hours, which is far beyond what any first load needs. Its practical constraint is payload size: a job accepts 150 MB of base64 encoded CSV, and because base64 inflates content by roughly a third, the working rule is to keep raw batches under 100 MB. Bulk API 1.0, if you are on an older integration, caps batches at 10,000 records or 10 MB. For incremental runs the REST query API is usually the better fit, since the volumes are small and you get results without job polling. Splitting the two paths is what keeps a backfill from consuming a day of API budget.
SystemModstamp, not LastModifiedDate
Both fields look like they mean the same thing and only one of them is safe as a replication watermark. LastModifiedDate reflects user edits and can be overwritten during data loads, so a bulk update by an administrator can leave records with a modified date in the past, which means your next incremental run filters them out and they never arrive. SystemModstamp is maintained by the platform and also advances when automated processes touch a record. Filter on SystemModstamp, store the high water mark from each run, and overlap the next window by a few minutes to absorb clock differences, relying on an upsert to make the overlap harmless. This single field choice is the difference between a sync that silently drifts and one that stays correct.
Text fields that do not fit the assumption
Salesforce allows 400,000 characters per record across all fields and 131,072 characters in a single field, which is comfortably larger than the varchar(255) that people reflexively create in Postgres for anything text shaped. Long text area fields, description fields and anything a rep pastes into a case comment will exceed it. Use text in PostgreSQL rather than a bounded varchar: there is no performance penalty in Postgres for doing so, and it removes an entire category of failure where a record refuses to load because somebody wrote a long note. Rich text fields also carry HTML markup, so decide once whether you are storing the markup or stripping it, and apply that consistently rather than per field.
A watermark query never sees a deletion
This is the gap that makes a Postgres replica of Salesforce slowly diverge, and it is invisible for months. Filtering on SystemModstamp returns records that changed. A record that was deleted no longer appears in the query results at all, so nothing tells your pipeline to remove it, and the row sits in Postgres forever. Reports built on that table then count opportunities and accounts that no longer exist in the CRM. There are two fixes and you want at least one. Salesforce keeps deleted records in the recycle bin for 15 days and exposes them through queryAll and the IsDeleted flag, so you can pull deletions on the same schedule. Or run a periodic reconciliation that compares the full id list per object and removes anything missing. The reconciliation catches anything older than the bin.
Concurrency limits, and how Adapters fits
One more ceiling worth knowing because it produces a confusing error rather than a clear one: Salesforce allows only 25 concurrent long running requests, meaning those over 20 seconds, in production and 5 in a Developer or sandbox org. Parallelize a backfill too aggressively across objects and you start getting errors that read like server problems and are actually your own concurrency. Keep the parallelism modest and the batches large rather than the other way round. Adapters runs this pair with those limits built into the schedule: bulk path for the first load, SystemModstamp filtering with an overlap window afterwards, upserts on the Salesforce id so re-runs are idempotent, deletion handling so the replica does not drift, and per-record error logs with the source values attached when a field refuses to land.
How it goes live
Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Connect Salesforce and Postgres with scoped credentials. About a minute each.
STEP 02
Confirm the mapping
The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.
STEP 03
Schedule the sync
Hourly down to every minute, with retries, alerting, and a full log on every run.
Prefer to understand the moving parts first? Our long-form guide to replicating Salesforce to Postgres covers the field-by-field detail, the failure cases, and what changes at volume.
Salesforce to Postgres sync: common questions
How do you sync Salesforce to PostgreSQL?
Through the Salesforce API into a staging area and then a merge into Postgres. Use the Bulk API for the initial backfill, then read incrementally on SystemModstamp and upsert on the 18 character record ID. The record ID makes a natural primary key because it is stable and globally unique across the org.
What Postgres types should Salesforce fields map to?
Id and lookup fields become CHAR(18) or TEXT, currency and number fields need explicit NUMERIC with the scale Salesforce reports rather than a float, checkboxes become BOOLEAN, and date and time fields become TIMESTAMPTZ because Salesforce returns UTC. Picklists are TEXT unless you genuinely want to maintain an enum alongside a changing picklist.
Why replicate Salesforce into Postgres instead of querying it live?
API limits and latency. Salesforce enforces a daily API allocation, and a customer facing feature that queries Salesforce on every page view will exhaust it and then fail. A Postgres replica gives your application millisecond reads, joins across objects that SOQL makes awkward, and no per query cost.
How do you handle Salesforce deletes in Postgres?
Query the deleted records endpoint and apply those deletes, or soft delete with a flag so downstream consumers can tell the difference. An incremental sync driven only by SystemModstamp will never notice a deletion, so records removed in Salesforce quietly live on in Postgres and skew every count built on the table.
How does the Salesforce to Postgres sync work?
The Salesforce to Postgres integration from Adapters replicates accounts, contacts, opportunities, and custom objects from the Salesforce API into Postgres tables on an incremental schedule, so your apps, internal tools, and reports read live CRM data with plain SQL instead of burning Salesforce API calls on every query. Field mapping is no-code.
Is there a prebuilt Salesforce connector for Postgres?
Yes. This Salesforce to Postgres connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.
How much does the Salesforce Postgres integration cost?
Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.
How often can Adapters sync Salesforce to Postgres?
Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.
Do I need to write code to connect Salesforce and Postgres?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads page the Salesforce API using the SystemModstamp watermark so each run pulls only new and changed records; the 18-character Salesforce Id becomes the Postgres primary key, currency fields cast to NUMERIC, ISO 8601 timestamps become timestamptz in UTC, and writes upsert on the Id so a retry updates in place instead of doubling rows.
More pairs from the API connector library
Browse the full api connector library, or request a pair you do not see.
Salesforce and Postgres, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
No credit card required.