How do I move data from Postgres to Snowflake?

Read changes from the Postgres write ahead log with logical decoding, land them in a staging table, then MERGE on the business key. That gives you a backfill and an ongoing sync from one mechanism. The step teams skip is overriding the default type mapping first, because Snowflake publishes two different mappings for this route and they disagree with each other on timestamps, arrays and currency.

What is the best Postgres to Snowflake connector?

Snowflake Openflow is the first-party answer and its published mapping is the more honest of the two Snowflake documents. AWS DMS fits when the source is already RDS or Aurora. Airbyte and Debezium fit teams who want to run it themselves. The connector matters less than whether you fix the timestamp, numeric and money mappings before the first load.

How do I connect Postgres to Snowflake?

Set wal_level to logical on the Postgres side, create a publication and a replication slot, then point a connector at it with a read-only role. On the Snowflake side create a landing schema and a small warehouse. The part that bites later is the replication slot, because an unconsumed slot keeps write ahead log files forever and can take the source database down.

How does Postgres to Snowflake data type mapping work?

Most types have an obvious target and a non obvious consequence. Every integer type lands in the same 38 digit NUMBER, so ranges stop being enforced. An unconstrained numeric can hold far more digits in Postgres than Snowflake can store. Snowflake has no interval column type and no time with time zone type. The full table further down gives every mapping and what each one costs you.

How much does Postgres to Snowflake replication cost?

The connector license is rarely the expensive part. What you pay for is Snowflake warehouse time during the backfill and every reload while you iterate on the mapping, plus per-row or per-event metering if your vendor bills that way. Budget for at least three full reloads, because the first two will be wrong in ways row counts do not reveal.

Can Snowflake run Postgres?

Yes, since 24 February 2026. Snowflake Postgres reached general availability that day and lets you create and manage Postgres instances directly from Snowflake, running on a dedicated virtual machine you connect to with any ordinary Postgres client. It is not a fork of Postgres. That makes lift and shift a real option that most guides in this category still do not mention.

Is Snowflake based on Postgres?

No. Snowflake's data warehouse is its own engine and shares no code with Postgres, which is why the type system differs so much. Snowflake Postgres, released separately in February 2026, is a managed service running standard Postgres rather than a fork. The two are different products that happen to sit in the same account.

What is the difference between Postgres and Snowflake?

Postgres enforces the schema and Snowflake mostly does not. Postgres has 2, 4 and 8 byte integers with real ranges, an interval type, a money type and case sensitive collation you control. Snowflake has one 38 digit number behind every integer alias, no interval column type, no money type and no time with time zone. Everything else follows from that.

How do I set up Postgres to Snowflake CDC?

Set wal_level to logical, create a publication over the tables you want and a replication slot for the consumer, then have the connector apply changes to Snowflake in micro batches rather than row by row, because Snowflake bills warehouse time and rewards batching. Monitor slot lag from day one and set an alert on it before you set one on the pipeline.

Should I use Fivetran or Airbyte for Postgres to Snowflake?

Fivetran if you want the pipeline to be somebody else's problem and your row volume is predictable, since it meters monthly active rows and a backfill is your largest month. Airbyte if you would rather run it yourself and spend engineering time instead of license fees. Both read the same Postgres write ahead log, so the mapping decisions on this page apply to either.

Postgres to Snowflake Connector, Migration Tools

Which Postgres to Snowflake migration tool should you use?

Use a change data capture connector that reads the Postgres write ahead log, because the same mechanism gives you both the backfill and the ongoing sync. Snowflake Openflow is the first-party option, AWS DMS fits when the source is already on RDS or Aurora, and Airbyte or Debezium fit teams who would rather run it themselves. Whichever you pick, override the default type mapping before the first load. Snowflake publishes two different mappings for this route and they contradict each other on timestamptz, time with time zone and arrays. Fix money first: the Openflow connector sends a Postgres money column to FLOAT, and PostgreSQL's own documentation says floating point should not be used for money because of rounding errors.

One correction worth making before anything else, because almost nothing written about this route has caught up with it. On 24 February 2026 Snowflake Postgres reached general availability, so you can now create and manage a real Postgres instance inside Snowflake and connect to it with any ordinary Postgres client. It is not a fork. If your reason for this project was consolidating vendors rather than getting columnar analytics, that is a materially shorter path than converting the type system. For the wider category see data migration tools, and for the continuous load rather than the one time move, Snowflake ETL tools.

Snowflake publishes two mappings for this route and they disagree

The SnowConvert PostgreSQL translation reference and the Openflow Connector for PostgreSQL data mapping page both describe how a Postgres column becomes a Snowflake column. Both are published by Snowflake. They give different answers for timestamptz, for time with time zone, for arrays and for bit strings, and only one of them lists money at all. We read both against the PostgreSQL manual on 3 September 2026. The last column is what we would actually ship.

Column type	What Snowflake's docs say	What the primary source says	What we would ship
timestamptz	SnowConvert maps TIMESTAMPTZ and TIMESTAMP WITH TIME ZONE to TIMESTAMP_TZ. Openflow maps the same type to TIMESTAMP_LTZ.	Openflow is right. PostgreSQL states that for timestamp with time zone "the value is stored internally as UTC, and the originally stated or assumed time zone is not retained", and on output it "is always converted from UTC to the current timezone zone". Snowflake's TIMESTAMP_LTZ "internally stores UTC values" and performs all operations in the session time zone, which is the same behavior. TIMESTAMP_TZ instead "stores UTC values together with an associated time zone offset", an offset Postgres never kept.	TIMESTAMP_LTZ, and set the warehouse TIMEZONE parameter deliberately
money	Openflow maps MONEY to FLOAT. SnowConvert does not list the type at all.	PostgreSQL's own money page says, in as many words, "Floating point numbers should not be used to handle money due to the potential for rounding errors." The connector does the exact thing the source database's documentation tells you not to do. Postgres money is a fixed fractional precision type ranging from -92233720368547758.08 to +92233720368547758.07, and its fractional digits depend on the lc_monetary setting of the database you read it from.	NUMBER(38,2), cast on the source as amount::numeric, never via float
time with time zone	SnowConvert maps it to TIME and notes "Time zone not supported for time data type", dropping the offset. Openflow maps TIMETZ to TIMESTAMP_TZ, keeping the offset but inventing a date.	Both are lossy and in opposite directions, because Snowflake has no time with time zone type at all. PostgreSQL agrees the type is a problem: "We do not recommend using the type time with time zone (though it is supported by PostgreSQL for legacy applications and for compliance with the SQL standard)."	Fix it in Postgres before you migrate. Store a timestamptz, or a TIME plus a separate zone column
bigint and int8	One SnowConvert table maps BIGINT to BIGINT and INT8 to INTEGER, two different targets.	In PostgreSQL bigint and int8 are two spellings of one 8 byte type with a range of -9223372036854775808 to +9223372036854775807. A single mapping table gives that one type two different Snowflake names. It matters less than it looks, because Snowflake's numeric page makes both synonyms for NUMBER(38,0) anyway, but a table that contradicts itself on the same row pair is not a table to accept unread.	NUMBER(38,0) explicitly, so nobody has to work out which alias won
smallint and int2	SnowConvert maps SMALLINT to SMALLINT and INT2 to SMALLINT. Openflow maps both to INT.	Openflow is the honest one. Snowflake's numeric data types page says SMALLINT is "Synonymous with NUMBER, except that precision and scale can't be specified (that is, it always defaults to NUMBER(38, 0))". PostgreSQL smallint is -32768 to +32767 in two bytes. Keeping the name SMALLINT reads as though the range survives the migration. It does not, and nothing raises an error the first time a six digit value lands there.	NUMBER(38,0) with CHECK (col BETWEEN -32768 AND 32767) where the range was load bearing
numeric, unconstrained	SnowConvert maps NUMERIC to NUMERIC with no note. Openflow maps it to NUMBER and adds "Scale and precision are preserved within Snowflake limitations".	That short caveat is doing a great deal of work. PostgreSQL states an unconstrained numeric column can store "up to 131072 digits before the decimal point" and up to 16383 after it. Snowflake's NUMBER tops out at 38 digits of precision. So a Postgres column with no declared precision has a theoretical range roughly 3,400 times wider in digits than the target can hold, and the mapping that mentions it does so in six words.	Measure MAX(LENGTH(col::text)) on the source first, then declare NUMBER(38,s) knowingly
arrays	SnowConvert maps type[] to ARRAY, noting "Strongly typed array transformed to ARRAY without type checking". Openflow does not list array types anywhere.	Openflow states "Any PostgreSQL data types not listed in this table are mapped to TEXT by default." Arrays are not in its table. So the same integer array becomes a semi-structured ARRAY under one Snowflake tool and a flat text string under another Snowflake tool, for the same source column on the same route. Whichever you get, the element type stops being checked.	ARRAY, and re-assert element types in the first transformation rather than trusting either default
character(n) and bpchar	SnowConvert maps BPCHAR to VARCHAR ("Not supported in Snowflake; VARCHAR used instead"). Openflow maps CHARACTER, CHAR and BPCHAR to TEXT.	Both name a reasonable target and neither mentions the comparison change. PostgreSQL says that for character(n) "trailing spaces are treated as semantically insignificant and disregarded when comparing two values", while "trailing spaces are semantically significant in character varying and text values". Snowflake's CHAR is only "Synonymous with VARCHAR", so it does not blank-pad. Equality on a padded code column can start returning fewer rows.	VARCHAR with RTRIM applied on load, then compare trimmed on both sides
VARCHAR maximum length	The SnowConvert note describes VARCHAR as defaulting "to max length (16,777,216)", presenting the default as the maximum.	Snowflake's own string data types page says "a VARCHAR value is also limited to a maximum of 134217728 bytes (128 MB)", with 16,777,216 being merely the default when no length is given. Meanwhile Openflow caps TEXT at 16 MB by default and BYTEA at 8 MB, both raisable. PostgreSQL's real ceiling is different again: "the longest possible character string that can be stored is about 1 GB."	Check MAX(LENGTH(col)) on the source against 128 MB, and raise the connector limit before the load
interval	Both documents agree: SnowConvert maps INTERVAL to VARCHAR as not supported, Openflow maps INTERVAL to TEXT.	Here the two agree and both are correct, which is worth saying on a page like this. Snowflake states plainly that "INTERVAL is not a data type (that is, you can't define a table column to be of data type INTERVAL). Intervals can only be used in date, time, and timestamp arithmetic." Any duration you stored as an interval becomes a string, and every query that did arithmetic on it needs rewriting.	Store the duration as a NUMBER of seconds plus a unit column, not as text

None of this makes either document useless, and we would still start with both. It makes the point that a published mapping is a starting position rather than a fact, even when the vendor publishing it owns the destination. The money row is the one to act on today. Everything else on this list costs you a reload, and that one costs you a finance reconciliation you cannot explain.

Postgres to Snowflake migration tools and connectors compared

Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. Where a tool is wrong for a job, the last column says so.

Tool	Approach	Best for	Pricing model
Snowflake Openflow	First-party managed connector reading the Postgres write ahead log	Teams already committed to Snowflake who want one vendor and one bill	Snowflake credits, metered as warehouse and service time
SnowConvert AI	Schema and SQL conversion, not a data mover	Translating DDL, views and functions before any rows move	Free to run
AWS DMS	Managed replication using Postgres logical decoding	Sources already on RDS or Aurora Postgres inside AWS	Metered by replication instance hour plus storage
Fivetran	Fully managed ELT with schema drift handling	Teams who want zero pipeline maintenance and have predictable volume	Monthly active rows
Airbyte	Open source connector framework, self-hosted or cloud	Engineering teams who prefer to own and patch the pipeline	Free self-hosted, capacity-based in cloud
Debezium	Change data capture into Kafka, then a sink into Snowflake	Estates that already run Kafka and want one change stream for many consumers	Free, you operate Kafka
Estuary Flow	Streaming CDC with a backfill from the same connector	Low latency requirements without operating Kafka yourself	By connector and data volume
Stitch	Simple managed ELT built on the Singer spec	Straightforward table copies where latency is not critical	Tiered by row volume
Matillion	Load plus in-warehouse transformation	Teams who want the modelling layer and the pipeline from one vendor	Credit-based consumption
dlt	Open source Python library you embed in your own code	Python teams who want pipelines as code in their own repo	Free, open source
Hevo Data	Managed no-code pipelines with in-flight transformation	Smaller teams wanting a managed pipeline without enterprise pricing	By events loaded per month
Adapters	Field-level mapping you set once, then scheduled incremental sync	Teams who want the mapping explicit and the bill flat	Flat $49 a month, not metered by rows

Snowflake Openflow

Snowflake

Where it loses: Its published mapping disagrees with Snowflake's own SnowConvert reference on timestamps, arrays and currency, and it sends money columns to FLOAT.

SnowConvert AI

Snowflake

Where it loses: It converts code and does not move data, and several of its published Postgres type notes need the corrections in the table above.

AWS DMS

Amazon

Where it loses: The instance runs whether or not data is flowing, and its own type conversion defaults are a third mapping to audit rather than a tie-breaker.

Fivetran

Where it loses: A migration backfill is the largest active-row month you will ever have, and reloads while you fix the mapping each bill again.

Airbyte

Where it loses: Self-hosting moves the cost from a license to your on-call rota, and Postgres CDC failure modes become your team's to diagnose.

Debezium

Community, Red Hat

Where it loses: You are adopting Kafka as well as a pipeline. Wrong shape unless the streaming platform is already there and staffed.

Estuary Flow

Estuary

Where it loses: A smaller connector catalog than the incumbents, so check your other sources are covered before standardizing on it.

Stitch

Qlik

Where it loses: Lighter transformation and mapping control than the rest of this list. Good at plain copies, thin when the mapping needs opinions.

Matillion

Where it loses: The transformation layer is the product. If you only need Postgres rows in Snowflake you are paying for a great deal you will not use.

dlt

dltHub

Where it loses: No scheduler, no UI and no alerting out of the box. You are building the operational half yourself.

Hevo Data

Hevo

Where it loses: Event-based metering behaves like row-based metering during a backfill, which is exactly when your volume spikes.

Adapters

Where it loses: We do not convert stored procedures, we are not the right tool for a pure one-time bulk lift, and we do not do in-warehouse modelling.

Postgres to Snowflake data type mapping, and what each conversion costs you

The target column is what the two Snowflake documents produce between them. The last column is what that mapping does to your data, which is the part neither mapping table carries. Read it before the first load, not after the first reconciliation meeting.

PostgreSQL type	Snowflake target	What it costs you
smallint, int2	NUMBER(38,0)	The 2 byte range of -32768 to +32767 stops being enforced. SnowConvert keeps the name SMALLINT, which reads as though it survived. It did not.
integer, int4	NUMBER(38,0)	Same story at 4 bytes. Arithmetic that overflowed loudly in Postgres now succeeds silently in Snowflake.
bigint, int8	NUMBER(38,0)	The 8 byte range disappears too, and the two spellings of this one type are given different targets by the same mapping table.
smallserial, serial, bigserial	NUMBER(38,0) with IDENTITY	PostgreSQL says these "are not true types, but merely a notational convenience". You get the column and lose the sequence, so the next value restarts unless you set it deliberately.
numeric, decimal	NUMBER(38,s)	An unconstrained Postgres numeric holds up to 131072 digits before the decimal point. Snowflake stops at 38 digits of precision. Measure before you declare.
real, float4	FLOAT	Snowflake stores all floating point as 64 bit, so a 4 byte real widens. Harmless, but sums will not match a source system that kept 4 byte arithmetic.
money	FLOAT by default	The row to change by hand. PostgreSQL states outright that floating point should not be used for money. Override it to NUMBER(38,2) and cast on the source.
timestamptz	TIMESTAMP_LTZ or TIMESTAMP_TZ	Two Snowflake documents pick different targets. LTZ matches Postgres behavior. TZ stores an offset that Postgres explicitly did not retain.
timestamp	TIMESTAMP_NTZ	A clean mapping. Both sides store wall clock time with no zone, so this one is genuinely safe.
time with time zone, timetz	TIME or TIMESTAMP_TZ	Snowflake has no equivalent type. One tool drops the offset, the other invents a date. Fix the column in Postgres first.
interval	VARCHAR	Snowflake cannot define a column as INTERVAL at all. Every duration becomes text and every query doing arithmetic on it needs rewriting.
character(n), bpchar	VARCHAR	Trailing spaces stop being ignored in comparisons, because they are insignificant in Postgres character(n) and significant in varchar and text.
text, varchar	VARCHAR	Postgres stores about 1 GB, Snowflake caps at 128 MB, and the default connector limit is lower again at 16 MB. Three ceilings, none of them equal.
bytea	BINARY	Postgres holds roughly 1 GB, the Openflow default accepts 8 MB. Raisable, but not raised for you, and oversized rows are where a load quietly drops data.
uuid	VARCHAR or TEXT	Once it is a string, ordering is by Unicode code point. Any keyset pagination or ORDER BY built on the UUID returns a different sequence.
json, jsonb	VARIANT	A good mapping, and the one place Snowflake is genuinely better. Note SnowConvert's Postgres table does not list either type, so only the connector documents it.
boolean, bool	BOOLEAN	Clean. Both engines have a real boolean, unlike the MySQL and SQL Server routes where it is an integer in disguise.
type[] (arrays)	ARRAY or TEXT	Depends which Snowflake tool you used. One converts "without type checking", the other has no rule and falls through to TEXT.
inet, cidr, macaddr	TEXT	Network types become strings, so subnet containment operators and address ordering stop working and become string comparisons.
tsvector, tsquery	TEXT	Full text search indexes do not come across in any usable form. Plan to rebuild search on Snowflake's own functions or leave it in Postgres.

The integer rows are the ones worth arguing about internally. Three distinct PostgreSQL integer types with three distinct ranges all land in the same 38 digit number, so every range check your schema performed for free is now something a CHECK constraint has to do. For the statement level version of this table, with the query that proves each risky row before you load it, see converting Postgres data types to Snowflake.

Eight failures that report success

None of these raise an error. Every one of them produces a green pipeline, a matching row count and a problem you find weeks later. The first one is the only entry on this page that can damage your production database rather than your warehouse.

Failure	What you see	What it actually costs
The replication slot nobody consumes	A pipeline is paused, deleted or misconfigured, and its slot is left behind on the source.	PostgreSQL states that slots "persist across crashes and know nothing about the state of their consumer(s). They will prevent removal of required resources even when there is no connection using them." The manual continues that "in extreme cases this could cause the database to shut down to prevent transaction ID wraparound." Your Snowflake sync looks idle while your production Postgres fills its disk.
Money arriving as a float	A money column maps to FLOAT by connector default and loads with no error.	Totals disagree with the source by fractions of a cent per row, which passes every row count check and fails the first finance reconciliation. PostgreSQL warns against exactly this.
Integer ranges that stopped being enforced	Every integer type becomes one 38 digit NUMBER and the load succeeds.	Values that could never exist in the source can now exist in the warehouse, so bad data flowing back from a downstream write is accepted silently instead of rejected.
Constraints accepted and ignored	Your primary keys and foreign keys are created in Snowflake without complaint.	Snowflake does not enforce PRIMARY KEY, UNIQUE or FOREIGN KEY on standard tables. Only NOT NULL and CHECK are always enforced, which makes CHECK the tool you rebuild guarantees with.
A replayed batch duplicating rows	A retry re-applies a batch that already landed and reports success.	With no unique constraint enforced, nothing rejects the duplicate. Land every batch in staging and MERGE on the business key rather than appending.
Oversized values truncated at the connector	A large text or bytea value exceeds the connector default of 16 MB or 8 MB.	The limits are raisable but not raised for you, so a handful of your largest rows are the ones affected and they are exactly the rows nobody spot-checks.
Timestamps shifted by a session parameter	timestamptz lands in TIMESTAMP_TZ instead of TIMESTAMP_LTZ.	Values render against a stored offset rather than the session zone, so daily aggregates near midnight move rows between days. Counts reconcile, day boundaries do not.
Padded codes that stop matching	A character(n) column becomes VARCHAR and keeps its trailing spaces.	Equality and joins on that column return fewer rows than in Postgres, because trailing spaces are ignored in character(n) and significant in varchar.

Six numbers that decide this migration

Every figure below was read from primary vendor documentation on 3 September 2026 and is sourced under the card. Where a vendor publishes no number, this page says so rather than inventing one.

24 Feb 2026

Snowflake Postgres reached general availability, letting you create and manage Postgres instances directly from Snowflake. Migrating is no longer the only way to get Postgres data into a Snowflake account.

Snowflake release notes, read 3 September 2026

2

Separate Snowflake documents publish a PostgreSQL to Snowflake type mapping, and they disagree on timestamptz, time with time zone, arrays and bit strings.

SnowConvert PostgreSQL data types and Openflow Postgres data mapping, read 3 September 2026

131,072

Digits before the decimal point an unconstrained PostgreSQL numeric column can store. Snowflake's NUMBER stops at 38 digits of precision.

PostgreSQL manual, Numeric Types, read 3 September 2026

128 MB

The real Snowflake VARCHAR ceiling, 134,217,728 bytes. The SnowConvert note quotes only the 16,777,216 default, and PostgreSQL stores about 1 GB.

Snowflake String and Binary Data Types, read 3 September 2026

0

Snowflake column types that can hold a PostgreSQL interval. Snowflake states INTERVAL "is not a data type" and can only be used in date and time arithmetic.

Snowflake Date and Time Data Types, read 3 September 2026

8 MB

Default size ceiling the Openflow connector applies to a bytea column, against roughly 1 GB in PostgreSQL. Raisable, but not raised for you.

Openflow Connector for PostgreSQL data mapping, read 3 September 2026

How to migrate Postgres to Snowflake in six steps

01

Decide whether you are migrating at all

Since 24 February 2026 Snowflake Postgres can run your Postgres instance inside Snowflake on a dedicated machine, reachable from any ordinary Postgres client, with no fork and no rewrite. If the goal was consolidating vendors rather than getting columnar analytics, that is a shorter project than a type migration. If the goal really is analytics at warehouse speed, keep reading.
02

Inventory the types that actually differ

Run one query against information_schema.columns and count the money, interval, timetz, array, network and unconstrained numeric columns. On most schemas that list is under twenty columns out of several hundred, and those twenty are the entire risk of the project. Everything else is a plain table every tool converts correctly.
03

Override the mapping before the first load, not after

Write the target DDL by hand for the columns on that list: NUMBER(38,2) for money, TIMESTAMP_LTZ for timestamptz, ARRAY with the element type reasserted downstream, NUMBER of seconds for intervals. Let the tool generate the rest. This is a day of work that removes most of the reloads.
04

Rebuild the guarantees Snowflake will not enforce

Snowflake accepts PRIMARY KEY, UNIQUE and FOREIGN KEY on standard tables and enforces none of them, while NOT NULL and CHECK are always enforced. So re-express the ranges you lost as CHECK constraints, and replace uniqueness with a post-load duplicate count you actually alert on.
05

Set up logical decoding and watch the slot first

Set wal_level to logical, create a publication and a slot, and put a monitor on slot lag before you put one on the pipeline. An unconsumed slot retains write ahead log indefinitely and PostgreSQL warns it can take the database down. This is the failure that hurts production rather than the warehouse.
06

Reconcile on values, never on row counts

Compare per table: the row count, the SUM of every numeric column, MIN and MAX of every timestamp, a count grouped by day, and a hash of the business keys. Row counts reconcile perfectly on a load that turned every money column into a float and shifted every timestamp by an offset.

Who moves Postgres into Snowflake, and why

Getting analytics off the production database

The most common reason this gets funded. Someone measured what the reporting queries were costing the application database and the answer was a page.

Joining Postgres to SaaS data already in Snowflake

The warehouse already holds Salesforce, Stripe or NetSuite data, and the application database is the last source that is not comparable with the rest.

Feeding BI and data science from one source of truth

Where separate extracts had drifted apart, one landing schema makes the numbers agree again, which is usually worth more than the migration costs.

Consolidating several Postgres instances

Estates grown by acquisition often run four or five databases with overlapping schemas. Snowflake becomes the first place they can be queried together.

Keeping both systems live indefinitely

The outcome nobody plans for and most teams reach. The application keeps Postgres, so the one time move quietly becomes an ongoing sync you have to operate.

Moving off a self-managed Postgres entirely

Here Snowflake Postgres is worth pricing against the migration, because since February 2026 lift and shift is a real alternative to a type conversion project.

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 we are the wrong answer and something on the list above is the right one.

Converting stored functions, triggers and PL/pgSQL. SnowConvert is built for it and free to run. We do not do it and would be worse at it.
A pure one time lift of a very large history with no ongoing sync. Export to Parquet and use COPY INTO. That is what it is for and it costs less than we do.
Air gapped environments with no outbound network. We are a hosted service. If nothing may leave your network, this is the wrong shape of product.
Sub-second replication latency across dozens of instances. That is the streaming CDC market and the specialists there earn their license fee.
Teams who need heavy in-warehouse modelling as well as the pipeline. Land the data with us if you like, but the transformation layer belongs in dbt or Matillion.

Four questions to ask any vendor on this list

Which of the two Snowflake mappings do you follow?

A fair question with no polite answer available, because Snowflake publishes two and they differ. Any vendor selling you this route should know that and have picked a side deliberately. Ask specifically what they do with timestamptz, money and arrays, and whether the answer came from the SnowConvert reference or the Openflow connector.

What happens to my money columns?

If the answer is anything containing the word float, stop. PostgreSQL's own documentation says floating point should not be used for money. The correct answer is a cast to numeric on the source and NUMBER(38,2) in the target, and a vendor who volunteers that has read the same pages you have.

How do you monitor the replication slot?

This is the question that separates people who have run Postgres CDC in production from people who have demoed it. An abandoned slot retains write ahead log until the source database is in trouble. Ask what they alert on, at what threshold, and what happens to the slot when you pause the pipeline.

What does the backfill cost, separately from steady state?

A migration backfill is not a normal month. On row or event based pricing it is the largest month you will ever have, and on credit based pricing it is a spike in warehouse time. Ask the vendor to price the backfill plus two reloads, because there will be reloads.

Related migration and warehouse guides

Postgres is one route into Snowflake among several. These cover the neighboring sources, the ongoing load case, and the cost model behind a migration program.

Questions buyers ask about Postgres to Snowflake migration

How do I move data from Postgres to Snowflake?: Read changes from the Postgres write ahead log with logical decoding, land them in a staging table, then MERGE on the business key. That gives you a backfill and an ongoing sync from one mechanism. The step teams skip is overriding the default type mapping first, because Snowflake publishes two different mappings for this route and they disagree with each other on timestamps, arrays and currency.
What is the best Postgres to Snowflake connector?: Snowflake Openflow is the first-party answer and its published mapping is the more honest of the two Snowflake documents. AWS DMS fits when the source is already RDS or Aurora. Airbyte and Debezium fit teams who want to run it themselves. The connector matters less than whether you fix the timestamp, numeric and money mappings before the first load.
How do I connect Postgres to Snowflake?: Set wal_level to logical on the Postgres side, create a publication and a replication slot, then point a connector at it with a read-only role. On the Snowflake side create a landing schema and a small warehouse. The part that bites later is the replication slot, because an unconsumed slot keeps write ahead log files forever and can take the source database down.
How does Postgres to Snowflake data type mapping work?: Most types have an obvious target and a non obvious consequence. Every integer type lands in the same 38 digit NUMBER, so ranges stop being enforced. An unconstrained numeric can hold far more digits in Postgres than Snowflake can store. Snowflake has no interval column type and no time with time zone type. The full table further down gives every mapping and what each one costs you.
How much does Postgres to Snowflake replication cost?: The connector license is rarely the expensive part. What you pay for is Snowflake warehouse time during the backfill and every reload while you iterate on the mapping, plus per-row or per-event metering if your vendor bills that way. Budget for at least three full reloads, because the first two will be wrong in ways row counts do not reveal.
Can Snowflake run Postgres?: Yes, since 24 February 2026. Snowflake Postgres reached general availability that day and lets you create and manage Postgres instances directly from Snowflake, running on a dedicated virtual machine you connect to with any ordinary Postgres client. It is not a fork of Postgres. That makes lift and shift a real option that most guides in this category still do not mention.
Is Snowflake based on Postgres?: No. Snowflake's data warehouse is its own engine and shares no code with Postgres, which is why the type system differs so much. Snowflake Postgres, released separately in February 2026, is a managed service running standard Postgres rather than a fork. The two are different products that happen to sit in the same account.
What is the difference between Postgres and Snowflake?: Postgres enforces the schema and Snowflake mostly does not. Postgres has 2, 4 and 8 byte integers with real ranges, an interval type, a money type and case sensitive collation you control. Snowflake has one 38 digit number behind every integer alias, no interval column type, no money type and no time with time zone. Everything else follows from that.
How do I set up Postgres to Snowflake CDC?: Set wal_level to logical, create a publication over the tables you want and a replication slot for the consumer, then have the connector apply changes to Snowflake in micro batches rather than row by row, because Snowflake bills warehouse time and rewards batching. Monitor slot lag from day one and set an alert on it before you set one on the pipeline.
Should I use Fivetran or Airbyte for Postgres to Snowflake?: Fivetran if you want the pipeline to be somebody else's problem and your row volume is predictable, since it meters monthly active rows and a backfill is your largest month. Airbyte if you would rather run it yourself and spend engineering time instead of license fees. Both read the same Postgres write ahead log, so the mapping decisions on this page apply to either.

For the people cost that dominates every migration program, read what a data migration really costs. For the mechanism that keeps Postgres and Snowflake in agreement afterwards, see Postgres logical replication, and for the wider vendor landscape, the best data integration tools. Snowflake publishes the same kind of conflicting pair of mappings for the commercial engine most teams are trying to leave, compared tool by tool in Oracle to Snowflake migration tools. The same disagreement runs across its own connector family too, which is why a boolean survives this route intact and does not survive MySQL to Snowflake migration.

Postgres to Snowflake migration tools compared: connectors, replication, data type mapping, and two Snowflake documents that map the same column to different types