Skip to content
Adapters

Informix to PostgreSQL migration tools and converters compared on what actually lands

Seven ways to move an IBM Informix database into PostgreSQL, judged on the rows that arrive. A popular converter maps DATETIME YEAR TO MINUTE onto DATE and drops the time of day, a floating DECIMAL(p) becomes a PostgreSQL type that keeps no decimals, and AWS DMS does not read Informix at all.

The live demo needs no card, and Starter is $49 a month.

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Vendor documentation read 7 October 2026

Which Informix to PostgreSQL migration tool should you use?

For a database built mostly from SPL procedures, use a code converter such as Ispirer or SQLines to draft the schema and PL/pgSQL, then correct the types by hand. AWS DMS and AWS SCT do not support Informix, so the usual AWS path is not available. For ongoing log-based capture, Qlik Replicate reads Informix CDC. For an ongoing sync during a long rewrite, use a tool that lets you declare the PostgreSQL columns, and map every DATETIME that carries a time to TIMESTAMP before any data moves.

Back office of a retail distribution center with a rack-mounted server cabinet beside shelves of shipping cartons
Informix still runs in the back room PostgreSQL next

This route sits under our data migration tools guide. Informix shares an owner with Db2, and the sibling route with its own type traps is on Db2 to PostgreSQL migration tools. The other legacy engine where a converter maps MONEY onto PostgreSQL MONEY is covered on Sybase to PostgreSQL migration tools.

Eight documented behaviors that change your data between Informix and PostgreSQL

Each row sets a tool's documentation against what IBM or PostgreSQL say about the same thing. The first one is a published type mapping from one of the best known converters on this route, and it treats a DATETIME that holds minutes as if it held only a day. IBM's own manual says otherwise.

Tool and setting What the documentation says Why it matters to a buyer What we would ship
SQLines, DATETIME The published map sends DATETIME YEAR TO MINUTE, YEAR TO HOUR and YEAR TO DAY to DATE. IBM: DATETIME "stores an instant in time expressed as a calendar date and time of day". YEAR TO MINUTE holds hours and minutes. A dispatch time of 4:45 PM on March 14 arrives as March 14, and nothing errors. TIMESTAMP(0)
SQLines, MONEY The map sends MONEY(p,s) to PostgreSQL MONEY. IBM: MONEY is "identical to DECIMAL(p,s)", up to 32 digits. PostgreSQL: MONEY precision comes from the lc_monetary setting. Under a US locale that is two decimal places. A MONEY(16,4) unit price or rate loses its last two digits on load. NUMERIC(p,s)
Any DDL copied as is, DECIMAL(p) IBM: in a database that is not ANSI-compliant, DECIMAL with fewer than two parameters is "a floating-point DECIMAL". PostgreSQL: NUMERIC(precision) selects a scale of 0. DECIMAL(8) held 12.75 on Informix. NUMERIC(8) stores 13. Totals drift by the cent on every row. NUMERIC, no scale
AWS DMS and AWS SCT Neither lists Informix. The DMS source list covers Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP ASE and Db2. SCT lists Db2, SQL Server, MySQL, Oracle, PostgreSQL and SAP ASE. The default path most teams moving to RDS or Aurora plan around does not exist for this source. Budget a converter
pgloader, Informix source The pgloader docs name CSV, fixed width, dBase and IXF files, and SQLite, MySQL, SQL Server and PostgreSQL databases. Informix is not documented. The free loader PostgreSQL teams reach for first does not read this source. Plan an UNLOAD and COPY step or another loader. UNLOAD, then COPY
Qlik Replicate, collections Qlik documents that "columns that follow columns of data types SET, MULTISET or LIST will not be replicated during CDC", and that CDC does not capture DDL. A table with a LIST column halfway along loads fully, then stops carrying changes to every column after it. Flatten collections first
Qlik Replicate, topology Replication from an Informix High Availability cluster is not supported. The database must be created WITH LOG or WITH BUFFERED LOG, and syscdcv1.sql run as DBA. Many production Informix servers run as HDR or RSS pairs. Capture has to come from a supported primary. Check topology first
Debezium, Informix Debezium says its Informix connector "is in an early stage of its development and is not recommended yet for production usage." Open source and log based, which looks ideal for a cutover. The vendor itself does not support that use yet. Pilot only

The first row is the one to take away. Informix lets a DATETIME column keep any span of fields, and YEAR TO MINUTE is a common choice for order, dispatch and work order times because it drops the seconds nobody needs. A map that treats every qualifier smaller than SECOND as a date loses the hours and minutes on exactly those columns, and the load raises no error because every value is a legal date. The third row is the quieter twin: only a database that is not ANSI-compliant treats DECIMAL(p) as floating, so check the mode before trusting any copied DDL. If the plan is to keep PostgreSQL current from Informix rather than move once, the capture options are compared in change data capture tools.

Informix types in PostgreSQL, and the wrong target a careless map picks

Most of an Informix to PostgreSQL conversion is easy. INTEGER, SMALLINT, BIGINT, DECIMAL(p,s), CHAR, VARCHAR, BOOLEAN and DATE cross with the same names. These twelve are where the obvious choice, or the one a tool makes for you, changes or loses data.

Informix type Right PostgreSQL target Common wrong target
DATETIME YEAR TO MINUTE TIMESTAMP(0) DATE, time of day dropped
DATETIME YEAR TO HOUR TIMESTAMP(0) DATE, hour dropped
DATETIME YEAR TO FRACTION(n) TIMESTAMP(n), n up to 5 TIMESTAMP(0) copied from the SECOND rule
DATETIME HOUR TO SECOND TIME(0) TIMESTAMP with an invented date
DATE from UNLOAD files DATE, DBDATE format checked Parsed as MDY when files were DMY
MONEY(p,s) NUMERIC(p,s) MONEY, two decimals under a US locale
DECIMAL(p), non-ANSI database NUMERIC, no declared scale NUMERIC(p), which rounds to whole numbers
SERIAL, SERIAL8, BIGSERIAL GENERATED BY DEFAULT AS IDENTITY A sequence left at 1 after the load
INTERVAL SECOND TO SECOND INTERVAL, or INT with the unit named INT with no record of the unit
BYTE, BLOB BYTEA TEXT, which rejects or mangles bytes
NCHAR, NVARCHAR CHAR, VARCHAR in a UTF8 database Read under the wrong DB_LOCALE
SET, LIST, MULTISET A child table or an array Dropped, or stored as one text blob

Two rows catch teams on settings rather than types. DBDATE controls how Informix writes dates into UNLOAD files, so the same column can export as 03/04/2026 meaning March 4 on one server and April 3 on another. DB_LOCALE controls how character data is read, and a mismatch converts accented names twice. Neither shows up in a schema diff. The procedural side of the same conversion, from FOREACH loops to RETURN WITH RESUME, is in our guide to converting Informix SPL to PostgreSQL.

Informix to PostgreSQL migration tools and converters compared

Billing units rather than price tags, because none of the commercial vendors here publish a list price for this route. Three names people search for are missing on purpose: AWS DMS and AWS SCT do not list Informix as a source, and pgloader does not document one. Where a tool is wrong for a job, the last column says so, including for us.

Tool Approach Best for Billing unit What to watch
Ispirer MnMTK Converts schema, data, SPL procedures, triggers and embedded SQL SPL heavy estates with a services budget Toolkit only, or toolkit plus services, quoted Review time drives the cost
SQLines SQL and SPL converter plus a data transfer tool over ODBC Teams that want to run the conversion in house Licensed tools, quoted DATETIME and MONEY defaults
credativ-pg-migrator Offline migration of models, data and SPL to PL/pgSQL Projects already working with credativ Not published Not yet open source, offline only
Qlik Replicate Log-based capture through the Informix CDC API Existing Qlik estates at high change volume Quoted license plus servers No HA cluster sources
Debezium Change Streams API into Kafka, then a sink Teams already running Kafka who can pilot Open source, you run Kafka Incubating, not for production
UNLOAD plus COPY Delimited export from dbaccess, PostgreSQL COPY on the other side A one-time move of a small database No license, staff time only DBDATE and locale on every file
Adapters Declared column mapping, incremental sync, per-record logs Typed PostgreSQL tables fed from Informix on a flat bill Flat monthly from $49, no per-row overage fees Does not convert SPL or 4GL

The missing AWS rows change the shape of the budget more than any line in the table. On Oracle, SQL Server, Sybase and Db2 the schema converter and the loader come with the cloud account, and the buyer's money goes on review. On Informix both are a purchase. For what a cutover of this size costs once the tools are chosen, see what a data migration really costs, and for a commercial engine where the AWS converter does exist and its defaults are the risk, the Oracle to PostgreSQL migration tools page.

Six numbers to know before you sign anything

0

Informix entries in the AWS DMS source list and in the AWS SCT source list. The AWS default path does not exist for this route.

AWS DMS and AWS SCT user guides, read 7 Oct 2026

80 to 90%

Share of Informix SPL that credativ says its migrator converts to PL/pgSQL, "depending on the writing style of the original code".

credativ announcement, 3 June 2025

5

The most fraction-of-a-second digits an Informix DATETIME can hold. The default is 3, so TIMESTAMP(0) drops real data.

IBM Informix 14.10 manual, read 7 Oct 2026

32

Significant digits an Informix MONEY or DECIMAL can store. Precision and scale have to be carried over exactly.

IBM Informix manual, read 7 Oct 2026

2

Decimal places a PostgreSQL MONEY column keeps under a US locale, whatever scale the Informix column had.

PostgreSQL manual, read 7 Oct 2026

1

Log-based CDC tools on this page that their own vendor supports for production use from Informix today.

Qlik and Debezium documentation, read 7 Oct 2026

Eight ways this migration goes wrong while every check stays green

Informix and PostgreSQL agree on more than their syntax suggests. Both have exact decimal types, both have serial style identity columns and both store intervals. The trouble sits in the places where a value is legal on both sides and means something different after it lands.

The failure What you see What is actually happening
Times disappear Row counts match DATETIME YEAR TO MINUTE went to DATE. Every timestamp now reads midnight, and shift and SLA reports collapse into one bucket per day.
Cents round away Totals close but not equal A floating DECIMAL(8) became NUMERIC(8), which keeps no decimals, so 12.75 was stored as 13.
Rates drift Invoice lines off by a fraction MONEY(16,4) became PostgreSQL MONEY and the third and fourth decimal places were rounded on load.
Months and days swap Some dates look plausible The UNLOAD files followed a DBDATE of DMY4 and COPY read them as month first, so every day up to the 12th loaded as the wrong date.
Accents turn to junk Names look wrong in a few rows The data was read under a DB_LOCALE that did not match the database, so non-ASCII characters were converted twice.
Columns stop updating Initial load passes every check A LIST column sat in the middle of the table, and CDC stopped carrying the columns after it.
A loop stops early Job reports success, fewer rows SPL used ON EXCEPTION WITH RESUME to skip a bad row and carry on. The PL/pgSQL handler ends the whole block instead.
IDs collide after cutover First insert fails on the key SERIAL columns were loaded with their values, but the new identity was never restarted above the maximum.

Three of the eight are fixed in the DDL before the first row moves. The date format and locale belong in the extraction runbook, the collection columns in the table design, and the exception handling and identity restart in code review and cutover. If PostgreSQL is a stop on the way to reporting, the loading side is covered on Postgres ETL tools.

Six steps that decide whether this migration works

Step 1

Confirm the version, mode and topology

Note the Informix version, whether each database is ANSI-compliant or not, whether it is logged, and whether the server is an HDR or RSS pair. ANSI mode decides what DECIMAL(p) means, and logging and topology decide which CDC tool can read it.

Step 2

Inventory the risky columns

Query syscolumns for every DATETIME with its qualifier, every MONEY and DECIMAL with precision and scale, every SERIAL, BYTE, BLOB, NCHAR and collection column. That list, not the table count, is the real scope of the type work.

Step 3

Write or correct the DDL by hand

Let a converter draft it, then apply the targets on this page: TIMESTAMP for any DATETIME with a time, NUMERIC(p,s) for MONEY, unconstrained NUMERIC for floating DECIMAL, child tables for collections. Create the tables before any loader runs.

Step 4

Pin the date format and locale

Set DBDATE and DB_LOCALE explicitly for every UNLOAD or extraction session and record them next to the files. Load a sample with days above 12 and accented names and read them back before running the full load.

Step 5

Full load, then keep PostgreSQL current

Load history once, then follow changes until the switch. With Qlik that means syscdcv1.sql on the server and a logged database. With a scheduled sync it means a reliable timestamp or SERIAL column to read increments from.

Step 6

Reconcile values, then restart identities

Compare SUM on every money and decimal column to the full scale, MIN and MAX on every timestamp, and counts by day. Restart each identity above the loaded maximum before the first write on PostgreSQL.

Step five is where a subscription earns its keep or does not. If the move is one weekend, UNLOAD and COPY do it and you are done. If Informix stays live for months while SPL and 4GL code are rewritten, you need the same mapping running every few minutes, with every DATETIME kept as a timestamp and a log of every record, which is what a flat Adapters plan covers with no per-row overage fees.

Why US teams fund this project

Retail and distribution back offices

Point of sale, store inventory and warehouse systems built on Informix decades ago still run in US chains and distributors. Their timestamps carry minutes for a reason, which is why the DATETIME mapping matters here first.

Telecom and utility operations

Provisioning, rating and work order systems run on Informix with sub-cent rates and minute-level event times. The rows are simple, the precision is not, and billing audits compare line for line.

State and local government systems

Case management, licensing and tax systems on Informix move to PostgreSQL to consolidate on one open database, under change control that wants every converted value proven, not sampled.

Manufacturing and plant floor data

Shop floor and quality systems record events to the fraction of a second. A conversion that drops fractions or minutes breaks every cycle time report the plant runs.

Moving to RDS or Aurora PostgreSQL

A cloud program has picked managed PostgreSQL, and then finds that AWS DMS and SCT do not read Informix. The open question becomes which converter and which loader replace them.

Running both during a long rewrite

Hundreds of SPL procedures and a 4GL front end take quarters to rewrite. Informix stays the system of record while PostgreSQL is kept current and checked against it, so the switch is a short window.

Five jobs where you should not pick us

A comparison page that never says the competition wins is an advert. These are the cases where something else on this page is the right answer.

  • Your database is mostly SPL procedures, triggers and 4GL code. That is a code conversion project, and Ispirer or SQLines are built for it. We do not convert procedural or application code at all.
  • You need log-based capture at high change volume with sub-minute lag, and you already own Qlik Replicate. It reads the Informix CDC API, and our scheduled sync will not beat it on latency.
  • The database is small and the move is one weekend. An UNLOAD per table and a PostgreSQL COPY costs nothing in licenses, provided someone checks DBDATE and DB_LOCALE on every file.
  • You already run Kafka and have engineers who can live with an incubating connector. Debezium is open source and log based, and a careful pilot may be all you need for a short cutover.
  • You are working with credativ on the migration already. Their migrator converts models, data and SPL in one offline pass, inside a services relationship you already have.

Four questions to ask any vendor on this list

Question 01

Which DATETIME qualifiers do you map to what?

The fastest question on this route. Ask for the target of YEAR TO MINUTE, YEAR TO FRACTION(5) and HOUR TO SECOND by name. Any answer containing DATE for the first one tells you where the times will go.

Question 02

What happens to MONEY and DECIMAL(p)?

The right answer is NUMERIC with the source precision and scale for MONEY, and NUMERIC with no declared scale for a floating DECIMAL. A PostgreSQL MONEY or a NUMERIC(p) is a reconciliation problem waiting.

Question 03

Can you read our topology and mode?

Ask about HDR and RSS pairs, unlogged databases and ANSI mode by name. Qlik rejects HA cluster sources and needs a logged database, so a vague "Informix supported" is not an answer.

Question 04

What does it cost when volume doubles?

Licenses, servers and Kafka capacity all grow with data. Ask for the bill at twice your current volume and for the month of the initial full load, which is often the most expensive month of the contract.

Questions buyers ask about Informix to PostgreSQL migration

How do I migrate from Informix to PostgreSQL?
Draft the schema with a converter such as Ispirer, SQLines or credativ-pg-migrator, then correct the DDL by hand: TIMESTAMP for every DATETIME that carries a time, NUMERIC(p,s) for MONEY, unconstrained NUMERIC for floating DECIMAL(p). Load history, keep PostgreSQL current until cutover, and reconcile on sums and timestamps rather than row counts.
What is the best Informix to PostgreSQL migration tool?
For a database built mostly from SPL procedures, Ispirer or SQLines do the bulk code conversion, with credativ-pg-migrator as a newer option. For ongoing log-based capture, Qlik Replicate reads Informix CDC. For keeping typed PostgreSQL tables current during a long rewrite on a flat bill, use a sync tool that lets you declare the target columns.
Does AWS DMS support Informix?
No. The AWS DMS source list covers Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP ASE and IBM Db2 for LUW and z/OS. Informix is not on it, and AWS SCT does not list Informix as a source either. Teams moving Informix into RDS or Aurora PostgreSQL need a third party converter and loader.
Can pgloader migrate Informix to PostgreSQL?
No. The pgloader documentation lists file formats such as CSV, fixed width, dBase and IBM IXF, and database sources such as SQLite, MySQL, MS SQL Server and PostgreSQL. Informix is not among them. The usual workaround is an Informix UNLOAD to delimited files and a PostgreSQL COPY, with the date format checked first.
Is there a Debezium connector for Informix?
Yes, but it is incubating. Debezium documents an Informix connector built on the Informix Change Streams API that takes a snapshot and then streams committed changes. Its own documentation says it is at an early stage and not yet recommended for production, so treat it as a pilot rather than the backbone of a cutover.
What is the PostgreSQL equivalent of Informix DATETIME?
It depends on the qualifier. DATETIME YEAR TO SECOND, YEAR TO MINUTE and YEAR TO HOUR all carry a time of day and belong in TIMESTAMP(0). YEAR TO FRACTION(n) belongs in TIMESTAMP(n), with up to five digits. Only YEAR TO DAY is a true DATE. HOUR TO SECOND belongs in TIME.
What is the PostgreSQL equivalent of Informix MONEY?
NUMERIC with the same precision and scale. IBM documents MONEY as identical to DECIMAL(p,s) with up to 32 digits. PostgreSQL also has a MONEY type, but its fractional precision comes from the lc_monetary locale, two digits for US dollars, so a MONEY(16,4) rate loses its last two decimal places.
How do I convert Informix stored procedures to PostgreSQL?
Use a converter for volume and a person for review. DEFINE becomes a declaration, LET becomes an assignment, FOREACH becomes a FOR loop and ON EXCEPTION becomes an EXCEPTION block. The hard parts are RETURN WITH RESUME iterator functions, ON EXCEPTION WITH RESUME and SYSTEM calls, which need a redesign rather than a translation.
Can I keep Informix and PostgreSQL in sync during the migration?
Yes. Qlik Replicate captures Informix changes through its CDC API once syscdcv1.sql has been run and the database is logged. Debezium has an incubating connector. A scheduled incremental sync on a timestamp or serial column works without touching the server and is the cheapest to run through a long rewrite.
How much does an Informix to PostgreSQL migration cost?
The tool is the smaller part. Ispirer and SQLines are licensed and quoted, Qlik Replicate is a quoted license plus servers, and Debezium is open source but needs Kafka to run. Rewriting and testing SPL and any 4GL application code dominates. An ongoing sync during the rewrite on Adapters starts at $49 a month.

For the wider vendor landscape see the best data integration tools, and if the same program is also moving an older MySQL estate, the MySQL to PostgreSQL migration tools page applies the same documented-defaults check to that route.

Keep PostgreSQL in step with Informix until the day you switch

Declare the columns once with TIMESTAMP where Informix had DATETIME YEAR TO MINUTE and NUMERIC(p,s) where it had MONEY, run the backfill, then let the same mapping sync incrementally with retries and per-record logs. From $49 a month, with no per-row overage fees.

The live demo needs no card, and Starter is $49 a month.

Get started