Salesforce Connect requires an OData endpoint to read external data as External Objects. If your database does not expose one natively (and most do not), you have two paths: build it yourself or use a managed service. This page compares the experience of building and maintaining a custom OData 4.0 adapter against using ForceCnx to generate one automatically.
How Custom OData Adapters Work
A custom OData adapter is a web service you build and host that translates OData protocol requests into queries against your database. The basic idea is straightforward: Salesforce sends an HTTP request like GET /odata/Products?$filter=Price gt 50&$top=10, and your service parses that request, runs the equivalent SQL query, and returns the results in OData's JSON format.
The challenge is in the details. The OData 4.0 specification is extensive. Your adapter needs to handle:
$metadatadocument: A CSDL (Common Schema Definition Language) document that describes every entity type, property, navigation property, and their data types. Salesforce reads this document to discover your schema and build External Object definitions.- System query options:
$filter,$orderby,$top,$skip,$select,$count, and$expand. Each has its own syntax and semantics.$filteralone supports dozens of operators and functions. - Pagination: Server-driven paging with
@odata.nextLinkfor large result sets. You need to generate stable continuation tokens and handle them correctly on subsequent requests. - Data type mapping: OData has its own type system (Edm.String, Edm.Int32, Edm.DateTimeOffset, Edm.Decimal, etc.) that must map correctly to your SQL column types.
- Error handling: OData specifies a structured error response format that Salesforce expects. Generic HTTP error responses will confuse the Salesforce Connect runtime.
- Authentication: Salesforce Connect supports named credentials with OAuth or basic auth. Your adapter needs to implement a compatible authentication scheme.
Most teams underestimate this scope. The initial prototype that handles simple GET requests takes a few days. Getting $filter and $orderby to translate correctly into parameterized SQL takes a few weeks. Handling edge cases, pagination, and the $metadata document can stretch into months.
How ForceCnx Works
ForceCnx connects to your PostgreSQL, Google Cloud SQL, or Amazon RDS database, introspects the schema, and generates a fully compliant OData 4.0 endpoint. You configure which tables and views to expose through the web UI, map fields to Salesforce-friendly names if needed, and ForceCnx handles the rest.
The generated endpoint includes a correct $metadata document, support for all standard query options that Salesforce Connect uses, server-driven pagination, proper error responses, and authentication via OAuth credentials you generate in the ForceCnx dashboard. There is no code to write, no server to host, and no OData specification to study.
Head-to-Head Comparison
| Dimension | Custom OData Adapter | ForceCnx | |---|---|---| | Setup time | Weeks to months | Minutes | | OData spec compliance | Depends on your implementation depth | Full OData 4.0 compliance | | $metadata generation | Manual — you maintain the CSDL document | Automatic from database schema | | $filter / $orderby | You implement each operator and function | Built-in, translates to optimized SQL | | Pagination | You implement continuation tokens | Server-driven paging included | | Hosting | You provision and manage infrastructure | Managed service, no servers to run | | Authentication | You implement OAuth or basic auth | OAuth credentials generated in dashboard | | Schema changes | Update code and redeploy | Re-sync in the UI | | Monitoring | You build observability | Included | | Ongoing maintenance | Bug fixes, dependency updates, security patches | Managed by ForceCnx | | Cost | Developer time + hosting costs | Subscription (free tier available) | | Database support | Whatever you build for | PostgreSQL, Cloud SQL, Amazon RDS |
When to Choose Custom OData Adapters
Building your own adapter makes sense in a few specific situations.
When you need a non-standard data source. If your data lives in a system that ForceCnx does not support (a legacy mainframe, a proprietary API, a graph database), you will need a custom adapter regardless. ForceCnx currently supports PostgreSQL-compatible databases.
When you need deep customization of the OData behavior. If you want to expose computed fields, aggregate data on the fly, or implement custom OData functions beyond what standard table/view exposure provides, a custom adapter gives you full control.
When you already have OData expertise on the team. If your organization has developers experienced with the OData specification and you already have infrastructure for hosting and monitoring web services, the build-vs-buy equation shifts. The marginal effort to build an adapter is lower when the knowledge is already in-house.
When you want zero external dependencies. Some organizations have policies against SaaS services touching their database connections. A self-hosted adapter keeps everything within your own infrastructure boundary.
When to Choose ForceCnx
ForceCnx is the better path for the majority of teams connecting relational databases to Salesforce.
When you want to move fast. Going from database to working External Objects in Salesforce takes minutes, not months. If you need the integration this quarter (or this week), ForceCnx eliminates the development cycle entirely.
When you do not have OData expertise. The OData 4.0 specification is hundreds of pages. Implementing it correctly, especially the query option parsing and metadata document generation, is a specialized skill. ForceCnx means you never need to read the spec.
When you want zero infrastructure to manage. No servers, no deployments, no uptime monitoring, no security patching. The endpoint is managed for you.
When schema changes are frequent. Adding a table or column to your exposed data set is a UI operation in ForceCnx. With a custom adapter, it requires code changes and a deployment.
When you want to minimize ongoing costs. The total cost of a custom adapter includes developer time to build it, infrastructure costs to host it, and ongoing developer time to maintain and update it. For most teams, a ForceCnx subscription is significantly cheaper than the fully loaded cost of maintaining a custom service.
Bottom Line
Building a custom OData adapter is a real engineering project with a long tail of maintenance. It makes sense when you have unusual requirements that no managed service can accommodate. For teams connecting PostgreSQL, Cloud SQL, or RDS to Salesforce, ForceCnx delivers a spec-compliant OData endpoint without writing or hosting any code. You get the same result in minutes instead of months, and you trade ongoing development work for a managed service that handles compliance, hosting, and updates for you.