“Should the target be PostgreSQL or SQL Server?” The question usually comes up in the first meeting of a data project, and in most organisations it has already been answered: whatever the corporate standard is, wins.
Even so, the cost of the decision does not sit in the standard. It collects in the small differences you meet while building the transfer definition. Both targets are supported in the same scope, and they do not behave identically.
The project definition does not change with the target
The verified external relational targets are PostgreSQL and Microsoft SQL Server. The project definition is the same for both: pick the source object, map the fields, create the target table or compare it with the existing structure, then set the load method and package settings. The command that starts the transfer goes to the SAP side, while table operations on the target run through database-specific query builders.
So this is an operations decision rather than an architecture decision. The question to ask is not “which one is faster?” but “which one already has your backup, monitoring and permission processes in place?”
Type mapping, key definition and write permissions
- Type mapping. The equivalents of SAP quantity, date and character fields are not identical in the two databases. Seeing decimal precision and text length in the mapping screen beats hunting truncation errors in production.
- Keys and upsert. The update-or-insert method rests on the key field definition. A definition with a missing key causes trouble on both targets, but the failure looks different.
- Table maintenance. Adding a field to the target table and removing an obsolete one can be done from the project. Ask early whether the database team runs a separate approval process for those operations.
- Permissions. Does the transfer user have create-table rights, or write only? That decides which table maintenance options are open to you.
Those four lines close the target debate in most projects. When they do not, the reason is rarely technical: two teams are running the same database at different levels of maturity.
Treating Fabric as a third relational target
Listing Microsoft Fabric as a third relational target is a common mistake. The flow from a SAP source into a Fabric target uses the OneLake path and works with Delta and Parquet file structures, not JDBC table operations. The Fabric Warehouse connection on the BI side is a separate connection type running over a Microsoft SQL Server compatible JDBC path.
Collapsing both into “Fabric support” plants a wrong assumption in the project plan: schema management, row counting and read behaviour differ between the two paths.
One more scope note: the verified external relational targets are those two. Do not write this flow into the plan for Oracle, MySQL or a cloud data warehouse target; if you need one, let us discuss it separately.
What we suggest for the decision: hold the target discussion around your operating model rather than throughput. Tell us which side is mature in your organisation, and we will build the same transfer definition against that target and review the type mapping field by field with you.