Deprecation of Databases for EnterpriseDB
IBM Cloud® is announcing the full deprecation of IBM Cloud® Databases for EnterpriseDB on 15 October 2025. After this date, any deployments of Databases for EnterpriseDB that are still running will be permanently disabled and deprovisioned.
The following describes the details of the deprecation, possible migration targets for your applications, and additional information.
Important dates
| Stage | Date | Description |
|---|---|---|
| Deprecation announcement | 17 January 2025 | Announcement of the Databases for EnterpriseDB deprecation. Existing instances will continue to run. |
| End of marketing | 16 June 2025 | No new instances of Databases for EnterpriseDB can be created or purchased. Existing instances will continue to run. |
| End of support | 15 October 2025 | Support is no longer available. Running instances of Databases for EnterpriseDB are permanently disabled and deprovisioned. |
Deprecation details
Review the following details about the Databases for EnterpriseDB deprecation:
-
A deprecation is a process, and we announced the beginning of that process. It begins with the announcement (this page), continues with end of marketing, and ends with end of support. Nothing happens until those announced dates above.
-
At the end of marketing, users who don't have Databases for EnterpriseDB running workloads will be blocked from deploying new applications. However, all users Databases for EnterpriseDB instances deployed can keep using them and restore from backups if necessary.
-
At the end of support stage, all Databases for EnterpriseDB deployments will be disabled and deleted.
-
All other services you have been using in IBM Cloud are unaffected — the Databases for EnterpriseDB deprecation refers only to the specific Databases for EnterpriseDB deployed instances.
-
Reminders of the approaching end of support date will continue to be sent periodically by email to all users that have Databases for etcd deployments.
Next steps for current users
The following is a suggested checklist to plan your migration:
- Understand and plan for the timeline and key milestone dates.
- Evaluate the IBM Cloud database migration options.
- Pick an IBM Cloud service migration database target that best meets your requirements and goals.
- IBM recommends ICD PostgreSQL for customer consideration. Also, refer to our blog post for detailed information on the latest PostgreSQL version.
- Migrate your data to the target IBM Cloud service and compare the operation of your applications.
- When ready, move application traffic as appropriate.
Migration to Databases for PostgreSQL
Migrating to Databases for PostgreSQL using a logical backup and restore approach is the supported method for migrating data from Databases for EnterpriseDB to Databases for PostgreSQL. The simplest and most effective method is creating a plain SQL dump using pg_dump and restoring it with psql. No special tooling is required, and the same approach can be used whether migrating between self-hosted or cloud-managed environments.
Before you start
- Target PostgreSQL version(s): Ensure your target PostgreSQL instance is version 14 or higher. PostgreSQL 13 has already been announced as deprecated. Hence, this strategy applies when migrating from Databases for EnterpriseDB 12 to Databases for PostgreSQL versions 14 through 17.
- ICD backup incompatibility: This migration approach is incompatible with proprietary ICD backups. Refer to the supplementary notes below for guidance on the logical backup and restore approach.
- Ensure that the source database does not use Oracle-style compatibility features or EDB proprietary objects.
pg_dump
On your source Databases for EnterpriseDB database, run pg_dump to create a plain SQL file that can be used to recreate the schema and data.
At a minimum, pg_dump takes:
- Hostname (-h)
- Port (-p)
- Database name (-d)
- Username (-U)
- File output path (-f)
Additional options:
-
Exclude system schema (-N sys): In EDB, the sys schema contains system-level Oracle-compatible functions and views (such as dual and dbms_output), which:
- Don’t exist in PostgreSQL.
- Will cause errors when restoring the dump to a plain PostgreSQL instance.
Example:
pg_dump -h <edb-source-instance>.databases.appdomain.cloud -p 51030 -U admin -d ibmclouddb -f edb_dump.sql -N sys
The pg_dump command has many options, and it is recommended that you refer to the official documentation for a complete list of capabilities.
Restoring pg_dump's output
The resulting output of pg_dump (for example, edb_dump.sql) can then be uploaded into a PostgreSQL deployment. Since it is plain SQL, it can be streamed directly to the database via psql.
Execute dump with psql, as in the following example:
psql -h <pg-target-instance>.databases.appdomain.cloud -p 32012 -U admin -d ibmclouddb -f edb_dump.sql
The psql tool reads and executes the SQL statements in the file. Ensure that you have proper privileges.
Notes
- This example assumes no Oracle-style compatibility or proprietary EDB objects.
- For complex schemas and fine-grained access control, consider reviewing --no-owner, --no-privileges, and role creation separately. Refer to the official documentation for more details.
- If you prefer other dump formats,
pg_dumpalso supports TAR format (-F t) and others.
For more information, see pg_dump documentation.
Using pg_restore for restoring the pg_dump's Output
If you used TAR or Directory formats (-F t or -F d), you must use pg_restore instead of psql.
pg_restore -h <pg-target-instance>.databases.appdomain.cloud -p 32012 -U admin -d ibmclouddb -F t edb_dump.tar
For advanced options, see the pg_restore documentation.
Submit a support ticket if you have any questions.