You have decided to use Salesforce Connect with OData to give your Salesforce users real-time access to external data. The architecture makes perfect sense: instead of copying data into Salesforce, External Objects query your database on demand through an OData endpoint. No stale data, no storage costs, no sync pipelines to babysit.
Then you hit the wall. Salesforce Connect needs an OData endpoint, and your database does not have one. PostgreSQL does not speak OData. Neither does MySQL, SQL Server, Cloud SQL, or RDS. There is no checkbox in your database admin panel that says "enable OData." You need a service layer between Salesforce and your database, and building one is where most Salesforce Connect projects stall or die.
This article breaks down your options for creating that OData endpoint, from building your own server to using a managed solution, with an honest assessment of the effort involved in each.
What Salesforce Connect Expects from an OData Endpoint
Before evaluating your options, it helps to understand what Salesforce Connect actually needs from an OData server. The requirements are specific, and partial compliance means broken integrations.
A Service Document at the root URL that lists all available entity sets (tables). Salesforce reads this during setup to discover what data is available.
A Metadata Document at the $metadata path that describes the schema of each entity set: property names, data types, key fields, and nullable flags. Salesforce uses this to auto-create External Object definitions with matching field types.
Entity set query support for the OData system query options that Salesforce uses. At minimum, your endpoint needs to handle $filter (for WHERE-style filtering), $orderby (for sorting), $top and $skip (for pagination), and $select (for field selection). Salesforce translates SOQL queries into these OData parameters, so your endpoint must translate them into the correct SQL and return properly formatted results.
HTTPS with valid certificates. Salesforce requires secure connections and will reject self-signed certificates.
Authentication. Your endpoint must support whatever authentication method you configure in the Salesforce External Data Source: basic auth, OAuth 2.0, or another supported method.
Reasonable response times. Salesforce imposes callout timeout limits. If your endpoint takes too long to respond, users see errors instead of data. This means your OData server needs to generate efficient SQL queries and your database needs appropriate indexes.
Getting all of these right is what separates a proof of concept from a production integration.
Option 1: Build a Custom OData Server
The most flexible approach is building your own OData server. You write an application that listens for HTTP requests, parses OData query parameters, translates them to SQL, executes them against your database, and returns OData-formatted JSON responses.
The technology landscape. The most mature library for building OData servers is Apache Olingo (Java). Olingo provides a framework for implementing OData 4.0 services, handling much of the protocol-level work (parsing query options, formatting responses, serving metadata). In the .NET ecosystem, Microsoft's OData libraries offer similar functionality. For other languages, options are thinner. There are partial OData implementations in Go, Python, and Node.js, but none match the completeness of Olingo or the .NET libraries.
What you still have to build. Even with a framework like Olingo, you are responsible for the data access layer: connecting to your database, translating OData queries to SQL, handling connection pooling, implementing error handling, and managing schema synchronization. You also need to build the deployment infrastructure, monitoring, and authentication layer.
Realistic timeline. For a team experienced with OData and the chosen framework, expect four to eight weeks to reach a production-quality endpoint for a single database. This includes handling edge cases in query translation, testing with Salesforce Connect specifically (which has its own quirks in how it generates OData requests), and building authentication.
Ongoing maintenance. Schema changes in your database require updates to your OData server's metadata. New tables require new entity set definitions. Query performance issues require SQL tuning in your translation layer. Security patches for your framework need to be applied. This is not a build-once-and-forget project.
Best for: Teams with strong Java or .NET development capabilities, complex query requirements that off-the-shelf solutions cannot handle, and the budget for ongoing maintenance.
Option 2: Enterprise Middleware (SAP Gateway, Progress DataDirect)
Several enterprise middleware platforms include OData endpoint capabilities as part of broader integration suites.
SAP Gateway is the standard OData implementation in the SAP ecosystem. If your external data lives in SAP systems, Gateway is the natural choice. However, if your data is in PostgreSQL or another non-SAP database, Gateway adds significant complexity and cost for a feature that is ancillary to its core purpose.
Progress DataDirect provides OData connectors for various databases as part of its data connectivity platform. It can expose databases as OData endpoints with configuration rather than code. However, DataDirect is an enterprise product with enterprise pricing, and it serves a much broader purpose than just Salesforce Connect integration.
Realistic assessment. Enterprise middleware makes sense when you already have the platform in place for other purposes, or when you need to expose data from multiple heterogeneous sources through a single integration layer. For a focused use case of connecting one or two databases to Salesforce, these platforms are typically overkill in both cost and complexity.
Best for: Organizations already invested in enterprise middleware platforms that happen to support OData, or multi-source integration scenarios that justify the platform cost.
Option 3: Cloud-Native API Gateways with OData Plugins
Some API management platforms offer OData support through plugins or extensions.
The challenge with this approach is that OData is not just an API format. It is a query protocol. An API gateway can proxy and authenticate OData requests, but it cannot generate OData responses from a raw database connection. You still need something behind the gateway that speaks OData, which brings you back to Options 1 or 2.
Some teams attempt to use a REST-to-OData translation layer, but OData's query semantics (especially $filter expressions, nested $expand, and $orderby on computed properties) are difficult to map from a generic REST API. The result is usually a partial implementation that works for simple cases but breaks when Salesforce issues more complex queries.
Best for: Adding authentication and rate limiting on top of an existing OData endpoint, not creating an OData endpoint from scratch.
Option 4: ForceCnx (Managed OData Endpoint)
ForceCnx was built specifically to solve this problem: turning a database into an OData 4.0 endpoint that works with Salesforce Connect, without any custom development.
How it works. You provide your database connection details (PostgreSQL, Google Cloud SQL, or Amazon RDS). ForceCnx connects, introspects the schema, and presents you with a list of tables and views. You select which ones to expose as OData entity sets. For each table, you configure field mappings: which columns to include, what to name them in the OData metadata, and how they map to Salesforce-compatible field types. ForceCnx then generates a fully compliant OData 4.0 endpoint that handles service documents, metadata, query translation, pagination, filtering, and sorting.
What you do not have to build. You skip the entire OData implementation. No query parser, no SQL translator, no metadata generator, no response formatter. You skip the deployment and infrastructure. ForceCnx hosts the endpoint. You skip the authentication layer. ForceCnx supports OAuth 2.1, generating client credentials that you configure directly in Salesforce.
Realistic timeline. From database connection to working External Objects in Salesforce: under an hour. Most of that time is spent in Salesforce's setup screens, not in ForceCnx.
Schema changes. When your database schema changes (new columns, new tables), ForceCnx detects the changes on the next introspection. You update your entity configuration in the ForceCnx dashboard, and then re-sync the External Objects in Salesforce. No code changes, no redeployment.
Cost. The free tier includes one database connection and up to five entity sets, which covers most initial integration scenarios. This lets you validate the entire architecture before making any financial commitment.
Best for: Teams that want to use Salesforce Connect but do not want to build, deploy, and maintain an OData server. Especially well-suited for Salesforce admins who are comfortable with configuration but do not have OData development expertise.
Choosing the Right Approach
The decision comes down to three factors: your team's capabilities, your timeline, and your ongoing maintenance budget.
If you have experienced Java or .NET developers, a unique query requirement that no off-the-shelf tool can handle, and a timeline measured in months, building a custom OData server gives you maximum control.
If you already operate an enterprise middleware platform that supports OData, leveraging it may make sense from a consolidation perspective, even if it is not the most direct path.
For everyone else, and that includes most Salesforce admins and teams evaluating Salesforce Connect for the first time, a managed OData endpoint eliminates the biggest barrier to adoption. You get to focus on the Salesforce side of the integration, which is where the real business value is, instead of spending weeks on OData server infrastructure.
The OData endpoint is the plumbing. It needs to work reliably, but it should not be the project. ForceCnx makes it the setup step it ought to be: configure, validate, and move on to building the Salesforce experience your users actually care about.