Migrating Sybase ASE aka SAP ASE to PostgreSQL

A lot of database migration projects start the same way - the business wants modernization, the platform team wants standardization and software that is safe and maintained with a proper release, and the executive leaders looking for Cost optimization strategies. Legacy Sybase ASE/SAP ASE databases are still powering mission-critical OLTP workloads, but modernization pressure keeps rising - especially when your Sybase to PostgreSQL roadmap is tied to platform standardization, cost control, or cloud adoption. This becomes more urgent when Sybase/SAP ASE versions hit "End of Mainstream Maintenance" and you need a predictable path forward with fewer production risks. In this article, we will cover some of the differences between SAP ASE and PostgreSQL, and a path forward for your legacy Sybase or SAP ASE database migration to PostgreSQL.

By the way, our commercial database migration tool, HexaRocket, now supports end-to-end Sybase/SAP ASE to PostgreSQL database migrations including - near to 100% automatic schema conversion, data migration and CDC for online migrations.

Journey from Sybase ASE → SAP ASE you should know

Sybase, Inc. was acquired by SAP in 2010. In the process of the acquisition, Sybase Adaptive Server Enterprise (Sybase ASE) was renamed to SAP ASE. And a small but useful history note for teams coming from SQL Server. Microsoft SQL Server originated from a partnership involving Sybase (and Ashton-Tate), then the products diverged - explaining why T-SQL syntax feels familiar in both ecosystems.

Please Note: SAP ASE 15.7 has reached End of Mainstream Maintenance (SAP notes indicate no further 15.7 releases are planned; you should validate dates against SAP’s current notes/PAM for your exact stack).

In this article, I will be mostly using SAP ASE as you now understand the journey. In case you see Sybase anywhere, you know what it is.

What SAP ASE supports (high-level inventory)

Following are the object types you generally encounter in this database engine.

• Tables
  • User Defined Types (UDTs)
  • Constraints
  • Triggers
  • Indexes
• Views
• Stored procedures
• Functions

PostgreSQL as a Target for SAP ASE

PostgreSQL is currently the most popular Open-Source relational database supporting workloads demanding both transactional as well as analytical capabilities. Postgres supports relational, unstructured, and also vector database capabilities with advanced sharding and partitioning techniques.

With its only growing popularity and rapid adaption rates as a migration target for other heterogenous databases, Postgres has become a primary choice for Infrastructure modernization and Cost optimization.

This also encouraged our company, HexaCluster, who is a proud contributor to Ora2Pg, pgBadger, and around 50 popular Open-Source tools and extensions of PostgreSQL, integrate the capabilities of seamlessly migrating SAP ASE workloads to PostgreSQL using an advanced database migration tool called HexaRocket.

Fundamental differences between SAP ASE vs PostgreSQL

Schema vs Owner model

• In SAP ASE, the owner (database user) behaves like a schema boundary. Objects are referenced as owner.object.
• In PostgreSQL, schemas are explicit namespaces (e.g., schema.table) and are controlled via search_path.

Default namespace - dbo vs public

• In Sybase ASE / SAP ASE, dbo is typically the default owner/namespace.
• In PostgreSQL, public is commonly the default schema (unless configured otherwise).
• During Sybase to PostgreSQL migrations, many teams either
  • Create a PostgreSQL schema named dbo and map Sybase dbo.* into it, or
  • standardize to public and adjust application qualifiers / search_path.

PostgreSQL does not have a drop-in equivalent for Sybase column validation rules; use CHECK constraints.

• Consider the following example in Sybase

1. Create the rule

   CREATE RULE positive_int AS @value > 0;
   
   GO
   

2. Bind the rule to a specific table and column

    EXEC sp_bindrule 'positive_int', 'schema.table.column';
   
    GO
   

• In the case of PostgreSQL, we rather use a CHECK constraint as follows.

  • ALTER TABLE table ADD CONSTRAINT table_col_positive_int CHECK (col > 0);
    

Index naming rule

• In Sybase ASE / SAP ASE, similar to SQL Server, it is common to reuse the same index name on multiple tables.
• In PostgreSQL, index names must be unique within a schema, so names must be adjusted during migration.

Built-in function gaps

• Many SAP ASE built-in functions don’t map 1:1 to PostgreSQL.
• In Sybase to PostgreSQL conversions -
  • We should use direct equivalents when available.
  • Otherwise we need to translate such built-in routines to PostgreSQL expressions, alternative functions, or small wrapper functions supporting the equivalent functionality. By the way, HexaRocket handles this as much as possible, in case you want to avoid the manual effort.

Sybase ASE / SAP ASE → PostgreSQL Data Type Mapping

SAP ASE data types and PostgreSQL data types have a lot of direct mapping with some attention required for some of the data types.

Sybase / SAP ASE Type	PostgreSQL Type	Notes
BIT	BOOLEAN NOT NULL	Sybase BIT does not allow NULL; use NOT NULL to preserve behavior.
TINYINT	SMALLINT	TINYINT is typically 0–255 (unsigned-like); PostgreSQL has no unsigned integer.
SMALLINT	SMALLINT	Direct mapping.
INT	INTEGER	Direct mapping.
BIGINT	BIGINT	Direct mapping.
UNSIGNED SMALLINT	INTEGER	Expand range because PostgreSQL has no unsigned integer.
UNSIGNED INT	BIGINT	Expand range.
UNSIGNED BIGINT	NUMERIC(20)	No unsigned 64-bit in PostgreSQL.
FLOAT	DOUBLE PRECISION	Closest equivalent.
REAL	REAL	Direct mapping.
DOUBLE/DOUBLE PRECISION	DOUBLE PRECISION	Direct mapping.
DECIMAL(p,s)	NUMERIC(p,s)	Same semantics.
NUMERIC(p,s)	NUMERIC(p,s)	Same semantics.
MONEY	NUMERIC(19,4)	Preserve scale/precision behavior.
SMALLMONEY	NUMERIC(10,4)	Preserve scale/precision behavior.
CHAR(n)	CHAR(n)	Direct mapping.
VARCHAR(n)	VARCHAR(n)	Direct mapping.
NCHAR(n)	CHAR(n)	If n is not declared, then, PostgreSQL text is typically sufficient.
NVARCHAR(n)	VARCHAR(n)	Same as above.
TEXT	TEXT	Direct mapping.
UNITEXT	TEXT	Unicode text maps to PostgreSQL text.
BINARY(n)	BYTEA	PostgreSQL stores binary as bytea.
VARBINARY(n)	BYTEA	Same as above.
IMAGE	BYTEA	Large binary objects.
DATE	DATE	Direct mapping.
TIME	TIME(6)	Use microsecond precision.
BIGTIME	TIME(6)	Same target precision.
DATETIME	TIMESTAMP(3)	Millisecond precision mapping.
SMALLDATETIME	TIMESTAMP(0)	Lower precision mapping.
BIGDATETIME	TIMESTAMP(6)	Microsecond precision mapping.
TIMESTAMP (ASE)	BYTEA or BIGINT (design choice)	ASE timestamp is often rowversion/binary counter, not date/time—don’t map blindly to PostgreSQL timestamp.
XML	XML	PostgreSQL supports native xml type.

We are glad to share that HexaRocket supports Sybase ASE / SAP ASE → PostgreSQL end-to-end migrations with -

• Schema conversion
• Data migration
• CDC/replication to support near-zero downtime cutovers

The result is a repeatable, production-grade Sybase to PostgreSQL pathway that database engineers or developers can operate confidently.

If you need expert support migrating legacy or complex Oracle, SQL Server, Sybase ASE, SAP ASE, MySQL, MariaDB databases to PostgreSQL or distributed databases, we’re here to help.

HexaCluster provides end-to-end migration and modernization services, including application migration and modernization, database migration, and PostgreSQL consulting such as performance tuning, health audits, managed DBA services, and 24/7/265 support.

To start a conversation or explore how we can support your migration journey, please contact us at connect@hexacluster.ai