PostgreSQL to Teradata: How to Move Your Data
Move PostgreSQL into Teradata with Airbyte. Why a replication slot is a production commitment, and why upstream views are the advantage here.
Moving PostgreSQL into Teradata brings application data into the environment where an organisation already models everything else. Where finance and operations live in governed subject areas, the database behind a product is often the missing piece.
This guide covers the managed path with Airbyte. Two things shape the build: change capture leaves something running on your source database that needs watching, and unusually for this destination you can do the reshaping before anything moves.
PostgreSQL to Teradata at a glance:
Why move data from PostgreSQL to Teradata?
Two situations account for most of these pipelines.
The first is bringing product data to where the analysts are. An organisation with a mature Teradata practice has conventions, access models and people who know the platform, and adding application data there beats asking everybody to learn a second environment.
The second is separating analysis from the database serving your product. If your organisation is not already committed to this platform, PostgreSQL to BigQuery achieves the same separation with considerably less modelling work.
What do you need before you start?
Four things, and the first needs your database administrator's agreement:
A replication slot and publication, with somebody watching them. Change capture depends on both, and a slot nobody consumes accumulates write-ahead log on your source. The PostgreSQL source documentation covers the setup.
A chosen SSL mode on the Teradata side. Encryption is off by default and two of the six modes permit an unencrypted connection, so the default is a decision rather than a safe fallback. The Teradata destination documentation lists them.
A schema name your organisation recognises. Tables land in a default schema called airbyte_td unless you specify otherwise, which is not a name that belongs in a governed environment.
A list of the tables you actually need. Each one is a modelling exercise here, so the selection is the project plan rather than a formality.
If either system restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow lists before you begin.
How do you build a PostgreSQL to Teradata pipeline in Airbyte?
Step 1: Agree the replication slot with whoever owns the database
Create the slot and publication together with your database administrator rather than announcing them afterwards, because a replication slot is a standing commitment on a production system. It tells PostgreSQL to retain write-ahead log until somebody reads it, which is exactly what makes change capture reliable and exactly what fills a disk if the pipeline stops. Agreeing monitoring now is much easier than explaining it later.
Step 2: Configure the PostgreSQL source
Click Sources in the left navigation, then New Source, and select PostgreSQL, following adding a source. Supply the host, port, database and credentials, then choose logical replication and name your slot and publication. Select views rather than raw tables where you have created them, for the reason below.
Step 3: Configure the Teradata destination
Click Destinations, then New Destination, and select Teradata, following adding a destination. Supply the host, credentials, logon mechanism and SSL mode, and name the schema rather than accepting the default. Check numeric precision on money columns before anybody reconciles a total.
Step 4: Create the connection and watch the slot
Click Connections, then New connection, select your streams and a sync mode. Then set up an alert on replication lag, because a failed pipeline here is a growing log on your production database rather than merely stale tables.
Deletions arrive through change capture, so decide what your model does with them rather than assuming rows simply vanish.
What does change capture leave behind?
A replication slot, which is the part of this arrangement that touches a production system. Logical replication works by having PostgreSQL retain write-ahead log until a consumer has read it, and the slot is the bookmark recording how far you have got. That retention is what makes the pipeline reliable and what makes it a shared responsibility.
The failure mode is worth stating plainly. If the pipeline stops and nobody notices, the slot stops advancing, the log keeps accumulating because PostgreSQL has been told somebody still needs it, and the disk fills on the database serving your product. That is a considerably worse outcome than a stale reporting table.
So treat monitoring as part of the build rather than an improvement. Alert on replication lag, agree with your administrator who responds when it grows, and drop the slot deliberately if you ever retire the pipeline rather than leaving it behind. In exchange you get deletions reaching your warehouse, which cursor-based reading never provides, and for a governed environment that completeness is usually the point.
Where should the reshaping happen?
Upstream, which is a luxury this pairing has and most do not. When the source is an API you take what it returns and reshape after landing; when it is a database you can create a view that produces exactly the shape you want and sync that instead, putting the work where the source's own types are understood.
That matters because Teradata is strict and PostgreSQL is generous. JSON columns, arrays and custom types are ordinary in a modern application schema and have no comfortable equivalent in a relational warehouse, so somebody has to unpack them. A view doing that before the sync means the destination receives columns it can model properly.
The same view is where you apply naming conventions, drop columns nobody will analyse and cast anything whose precision matters. It is visible to anybody reviewing the pipeline, versioned alongside your application if you keep migrations in code, and far easier to reason about than a transformation buried downstream. Use it, because with an API source this option is not available.
Frequently asked questions
What happens if the pipeline stops?
The replication slot stops advancing and write-ahead log accumulates on your source database. Alert on replication lag so this is noticed rather than discovered.
Should I sync tables or views?
Views, where your tables contain JSON, arrays or custom types, since a strict destination has no equivalent and reshaping upstream is easier than afterwards.
Is the connection encrypted by default?
No. SSL is off by default and two of the six modes permit unencrypted connections, so choose a mode deliberately.
Do deletions reach Teradata?
With logical replication, yes, which is one of the better reasons to accept the replication slot's operational cost.
Can I do this without writing code?
The pipeline, yes, though the slot and publication are database administration. The upstream views are SQL and they are what makes the destination comfortable.
Get your PostgreSQL data into Teradata
Agree the replication slot with your database administrator and alert on lag from the start, because a stopped pipeline here grows the log on a production system rather than merely going stale. Set the SSL mode and name your schema. Then use the advantage a database source gives you: shape the data in upstream views so a strict destination receives columns it can model rather than types it cannot hold.
Airbyte's connector catalog includes 600+ pre-built connectors, so application data can be modelled beside everything the business measures. For an enterprise database into the same destination, see Oracle Database to Teradata, and for a warehouse into the same destination, BigQuery to Teradata.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.