Эти проекты, конечно, не показатель. Насколько я помню максимумы, это около 300 таблиц и 30 Гб. Индексы и ограничения мигрировали, вьюх и хранимок в этих проектах принципиально не было, только код C# + EF Core.

В Postgre довольно давно есть uuid, надо бы поправить

благодарю, есть, но он не совместим с SQL Server GUID:
PostgreSQL UID 40e6215d-b5c6-4896-987c-f30f3678f608 https://www.postgresqltutorial.com/postgresql-uuid/
SQL Server GUID BAE7DF4-DDF-3RG-5TY3E3RF456AS10 https://docs.microsoft.com/en-us/sql/t-sql/data-types/uniqueidentifier-transact-sql

Мы GUID не использовали в нашей системе, но логично предположили что аналога в CHAR(16) будет для быстрой миграции достаточно, а уже в целевой базе данных что с ними делать это отдельный вопрос

сегодня кстати добавил в статьи Guid vs INT - Which is better as a primary key? https://dba.stackexchange.com/q/264/107045

Почему не совместим, я через связанный сервер передавал с мс в постгри гуид, и он норм ложился

BAE7DF4-DDF-3RG-5TY3E3RF456AS10  что это за пример?

ну если такой не нравится, то может этот лучше 6F9619FF-8B86-D011-B42D-00C04FC964FF? предыдущий взят с ответа на stackoverflow, там SQL Server 2005 упоминается

а. увидел. https://blog.codinghorror.com/primary-keys-ids-versus-guids/
но всеравно не понятно.
т.к. uuid с моей точки зрения всеголишь строковое преставление очень длинного числа, в виде hex-цифр. [0-9A-F]

это то да, но при этом и нет
> By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f.

Передаем различными способами в хранилище GreenPlum из различных источников MS SQL, проблем не было.
А вот при использовании GUID char(16) в качестве PK были глобальные проблемы с быстродействием PostgreSQL. После перехода на uuid проблемы практически ушли.

Хмм... а в чём несовместимость-то, конкретно?

не знаю, внешне он длиннее (здесь можно шутку что у SQL Server короче чем у PostgreSQL), ни разу не пробовал переносить GUID из SQL Server куда-либо, если есть опыт - буду рад обратной связи

Цитируя тот же https://docs.microsoft.com/en-us/sql/t-sql/data-types/uniqueidentifier-transact-sql?view=sql-server-ver15 :
Is a 16-byte GUID.
tring constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value.

И https://www.postgresql.org/docs/current/datatype-uuid.html :

The data type uuid stores Universally Unique Identifiers (UUID) <skip> (Some systems refer to this data type as a globally unique identifier, or GUID, instead.) This identifier is a 128-bit quantity <skip>

A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing the 128 bits.
И, если сравнить форматы и примеры из документаций:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -- MS SQL
6F9619FF-8B86-D011-B42D-00C04FC964FF -- MS SQL
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11 -- PostgreSQL

Что тут "длиннее"?

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -- MS SQL
6F9619FF-8B86-D011-B42D-00C04FC964FF -- MS SQL
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11 -- PostgreSQL

для PostgreSQL я брал с другого ресурса пример, там длинее:
40e6215d-b5c6-4896-987c-f30f3678f608 https://www.postgresqltutorial.com/postgresql-uuid/
BAE7DF4-DDF-3RG-5TY3E3RF456AS10 https://docs.microsoft.com/en-us/sql/t-sql/data-types/

Вставить то можно, но будет ли он поддерживать уникальность также как в SQL Server - я не знаю, поэтому если есть практический опыт переноса, буду рад его себе сохранить

CREATE TABLE t(u uuid);
INSERT INTO t(u) VALUES ('6F9619FF-8B86-D011-B42D-00C04FC964FF');
INSERT INTO t(u) VALUES ('6F9619FF8B86D011B42D00C04FC964FF');
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
INSERT INTO t(u) SELECT uuid_generate_v1();

SELECT * FROM t;

CREATE TABLE t(u uuid);
INSERT INTO t(u) VALUES ('6F9619FF-8B86-D011-B42D-00C04FC964FF');
INSERT INTO t(u) VALUES ('6F9619FF8B86D011B42D00C04FC964FF');
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
INSERT INTO t(u) SELECT uuid_generate_v1();

SELECT * FROM t;

Не стоит брать примеры с "левых" ресурсов, что тут ещё скажешь... ;)
(Да, PostgreSQL поддерживает альтернативные input formats для UUID, если что.)

PostgreSQL also accepts the following alternative forms for input: use of upper-case digits, the standard format surrounded by braces, omitting some or all hyphens, adding a hyphen after any group of four digits.

> Вставить то можно, но будет ли он поддерживать уникальность также как в SQL Server

Хмм... а что это значит? В PostgreSQL тоже есть генераторы значений UUID (в расширениях), а уникальность гарантируют только индексы, как всегда.

PostgreSQL also accepts the following alternative forms for input: use of upper-case digits, the standard format surrounded by braces, omitting some or all hyphens, adding a hyphen after any group of four digits.

GUID в SQL Server гарантирует уникальность сгенерированых индефекаторов глобально без привязки к серверу и т.д. (колизии все равно вроде как возможны - не смог найти статью, поэтому кому интересно может поискать), как это реализовано в PostgreSQL я не знаю и что будет при импорте большего количества значений GUID из SQL Server  в PostgreSQL я тем более не знаю

Не "гарантирует" теоретически (это, очевидно, невозможно), просто коллизии UUID-ов практически невероятны. ;)

> как это реализовано в PostgreSQL

Так же. Т.е. это всё стандартные решения (кроме NEWSEQUENTIALID и ему подобных), Microsoft тут ничего не изобрёл, насколько я помню.

Ставь лайк, если тоже боишься, что когда-нибудь GUID-ы закончатся и поэтому стараешься лишний раз их не генерировать

Вероятность коллизий существует в любом рандомизированном алгоритме, вопрос лишь в том насколько высока вероятность. Из личного опыта: словил коллизию на гуиде сиквельном,  но это было один раз за почти 20 лет опыта .

Вроде бы нормальный guid в постгресе, выглядит вполне обычно
конвертнул из MS SQL

SELECT CAST('0A473B9C-4D8B-413E-8427-8AEF0F239937' AS uuid);

сгенерил
SELECT md5(random()::text || clock_timestamp()::text)::uuid;

SELECT CAST('0A473B9C-4D8B-413E-8427-8AEF0F239937' AS uuid);

в пг готовые функции для генерации есть.