A data migration from SQL Server to PostgreSQL rarely fails at actually copying the data. It fails at the silent differences that only surface in the target: datetime, which knows no time zone, bit, which is not a boolean, an IDENTITY that turns into a sequence, and a collation that suddenly compares case-sensitively. Anyone who sets out to migrate SQL Server to PostgreSQL isn’t … Read more
The row counts match — table by table, source against target, all green. And yet the migration isn’t finished. In one column, NULL values have turned into empty strings; in another, the detour through a CSV file rounded the last decimal of an amount; and a handful of accented characters collapsed into question marks. Same count is not … Read more
The data is over, the schema stands — and then there are 200 stored procedures sitting there that no tool translates for you. pgloader migrates tables and data, but the logic in procedures, functions, and triggers stays behind. This is the phase that’s actually work: porting T-SQL to PL/pgSQL, line by line, with understanding instead of search-and-replace. The … Read more
Moving data sounds like the easiest phase of a migration: the table is there, pour the data in, done. Until the first larger table takes a whole afternoon — because it runs row by row via INSERT instead of in one sweep via COPY. Anyone who needs to load data into PostgreSQL has four routes to choose from, and the … Read more
A SQL Server to PostgreSQL schema migration looks finished the moment the CREATE TABLE script runs without an error. That is exactly when the real trouble begins: the table is there, the data is loaded — and the first INSERT that should hand out a new ID collides with an existing key. The reason is not a typo but a change … Read more
A migration from SQL Server to PostgreSQL rarely fails at actually copying the data. It fails at datetime, where the choice between timestamp and timestamptz is anything but cosmetic, at bit, which is not a boolean, and at money, which you’d be better off not touching in PostgreSQL at all. The SQL Server to PostgreSQL data type mapping decides whether the data arrives cleanly — … Read more
Bad data gives no warning. An age of 200 years, a duplicate customer number, a country code that doesn’t exist — in the source system nobody notices. Only when the ETL run tries to push the rows into the strictly modelled target layer does the load break: on a CHECK, on a UNIQUE index, on a foreign key. Checking … Read more
“We do ETL.” You hear it in almost every data team — and it is often wrong. If every transformation runs as a stored procedure after the raw data has already been loaded, unchanged, into a staging table, then what you have is really ELT. The label hides what is actually happening. The difference between ETL vs. ELT is … Read more
If you write a stored procedure, you write it for someone who doesn’t know it — usually for yourself, 18 months later, at 11 p.m., while an ETL run is stuck. Readability isn’t cosmetics, it’s debugging time. PostgreSQL forces almost nothing on you: names are free, indentation doesn’t matter, a RAISE EXCEPTION swallows any string you assemble inline. That’s exactly … Read more
A single date string that cannot be parsed, and the entire ETL run aborts. The design pattern for ETL process architecture presented here prevents exactly that: bad data is isolated, not passed along. TL;DR — what this article covers: Prerequisite. Basic familiarity with ETL processes. This is a conceptual article — not a step-by-step tutorial. The technology examples are … Read more
