If you have business-critical data sitting in a PostgreSQL database and a team that lives inside Salesforce, you already know the frustration. Sales reps want to see order history. Support agents need account details. Executives want dashboards that combine CRM data with operational metrics. But the data lives in two completely different systems, and getting it into Salesforce feels like it should be simpler than it is.
The traditional answer has been ETL: extract the data from PostgreSQL, transform it to fit Salesforce's schema, and load it into custom objects. But ETL introduces stale data, storage costs, sync failures, and ongoing maintenance. There has to be a better way.
There is. It is called Salesforce Connect, and when paired with an OData endpoint, it lets your Salesforce users query PostgreSQL data in real time without copying a single row.
The Problem with Getting External Data into Salesforce
Salesforce is a closed ecosystem by design. It has its own database, its own query language (SOQL), and its own object model. When your data lives outside Salesforce, you have limited options for making it accessible to your users.
The most common approach is ETL (Extract, Transform, Load). Tools like MuleSoft, Informatica, or even custom scripts pull data from your PostgreSQL database on a schedule, transform it to match Salesforce custom objects, and push it in via the Salesforce API. This works, but it comes with serious downsides.
First, your data is always stale. Whether you sync every hour or every fifteen minutes, there is a window where Salesforce does not reflect reality. For fast-moving data like inventory levels, order statuses, or pricing, that staleness creates real problems.
Second, you are paying for Salesforce storage twice. Every row you copy into Salesforce counts against your data storage allocation. At enterprise scale, that cost adds up fast. Salesforce charges a premium for additional storage, and suddenly your integration is also a line item on your Salesforce invoice.
Third, ETL pipelines break. Schema changes in your source database, API rate limits, authentication token expirations, network timeouts. Each of these becomes an ongoing maintenance burden. Someone has to monitor the pipeline, fix failures, and verify data integrity. It is never truly "set and forget."
Finally, there is the transformation complexity. PostgreSQL and Salesforce have different data types, different naming conventions, and different relationship models. Mapping between them requires careful planning, and every schema change on either side risks breaking the integration.
How Salesforce Connect Solves This
Salesforce Connect takes a fundamentally different approach. Instead of copying data into Salesforce, it queries the external system on demand. When a user opens a record, runs a report, or executes a SOQL query that involves external data, Salesforce reaches out to the external system in real time, fetches the relevant rows, and displays them as if they were native Salesforce records.
The mechanism behind this is External Objects. Unlike standard or custom objects, External Objects do not store data inside Salesforce. They are metadata definitions that describe the shape of your external data and tell Salesforce how to retrieve it. External Objects support most of the features you expect: list views, detail pages, related lists, reports, and even lookup relationships to standard Salesforce objects.
Salesforce Connect supports several protocols for communicating with external systems, but the most flexible and widely used is OData 4.0. OData is an open standard for building and consuming RESTful APIs, and it provides a consistent way to query, filter, page, and sort data over HTTP. When you configure Salesforce Connect with an OData endpoint, Salesforce translates SOQL queries into OData requests and maps the responses back into External Object records.
This means your data stays in PostgreSQL. You do not pay for Salesforce storage. The data is always fresh. And you do not need a complex ETL pipeline to keep things in sync, because there is nothing to sync.
The Missing Piece: An OData Server
There is one catch. Salesforce Connect needs an OData endpoint to talk to, and PostgreSQL does not natively speak OData. You need something in between, a service that accepts OData requests from Salesforce, translates them into SQL queries, runs them against your PostgreSQL database, and returns the results in OData format.
Building this yourself is certainly possible, but it is not trivial. The OData 4.0 specification is extensive, covering query options like $filter, $orderby, $top, $skip, and $select. You need to handle authentication, connection pooling, error handling, and schema negotiation. For most teams, building and maintaining a custom OData server is a project in itself, one that distracts from the actual goal of surfacing data in Salesforce.
This is where ForceCnx comes in. ForceCnx is a purpose-built OData server designed specifically for Salesforce Connect. You point it at your PostgreSQL database, it introspects your schema automatically, and it generates a fully compliant OData 4.0 endpoint that Salesforce Connect can consume directly.
How It Works in Practice
The setup process has three main steps.
First, connect your database. In ForceCnx, you provide your PostgreSQL connection details: host, port, database name, and credentials. ForceCnx supports direct connections, Google Cloud SQL, and Amazon RDS. Once connected, it reads your database schema and presents you with a list of available tables and views.
Second, configure your entities. You choose which tables you want to expose to Salesforce. For each table, you select which columns to include and how they should be named in Salesforce. This field mapping step lets you translate PostgreSQL naming conventions (like snake_case) into Salesforce-friendly labels without changing anything in your source database.
Third, connect Salesforce. In Salesforce Setup, you navigate to External Data Sources and create a new data source using the OData 4.0 adapter. You enter the ForceCnx endpoint URL and configure authentication. Salesforce validates the connection and lets you sync the schema. This creates External Objects in your Salesforce org that map to the tables you selected in ForceCnx.
From that point forward, your PostgreSQL data is available inside Salesforce. Users can view records, add External Objects to page layouts as related lists, build reports, and query the data with SOQL, all without any data ever being copied.
Why This Matters for Your Team
The real value is not just technical elegance. It is about what your team can do once external data is seamlessly available in Salesforce.
Sales reps can see real-time order status, inventory levels, or pricing data directly on Account and Opportunity records, without switching to another application or waiting for a nightly sync.
Support agents can look up transaction histories, shipping details, or usage metrics from within the Case record they are already working on.
Operations teams can build Salesforce reports that blend CRM data with operational data from PostgreSQL, giving leadership a complete picture without manual data assembly.
Admins can set this up without writing code, without managing ETL infrastructure, and without worrying about Salesforce storage limits. External Objects do not count against your org's data storage allocation.
Getting Started
If you have data in PostgreSQL that your Salesforce users need to see, Salesforce Connect with an OData endpoint is the cleanest path to get there. ForceCnx eliminates the hardest part of that setup by giving you a production-ready OData server without any custom development.
The free tier supports one database connection and up to five entities, which is enough to validate the approach with your team before committing to a broader rollout. You can have your PostgreSQL data visible inside Salesforce in under an hour, with no code, no ETL, and no data duplication.
Stop copying data between systems. Start querying it where it lives.