Achei interessante a abordagem 🤔. Eu nunca tinha parado pra pensar sobre porque no final, aqui onde trabalho, usamos um backup do banco de prod localmente (importante notar que fazemos isso pois não há dados sensiveis expostos nessa base). Então basicamente, há uma rotina de backup do banco de dados de prod e conseguimos puxar esse backup e upar no nosso postgres local pra trabalhar.

Provavelmente não é aplicável pra tí porque seu banco de dados tem 2TB.

Sobre o Amazon DMS

Sei que o DMS que você comentou faz migração parcial dos dados mas o problema de garantir que todas as relações estão "completas" (e.g. vir um usuário, mas por ventura na migração não vir a relação usuário-grupo) persiste. Seria uma complexidade a mais. Pesquisei rapidinho e vc pode ver os preços aqui. Basicamente o preço é por hora de computação. O lado bom é que tem free tier, então vc pode testar de graça por até 1 ano e ver se serve pra você 😄

Sobre a solução interna de ETL

Aqui é mais meus 2 cents em relação à solução que você pensou.

Acho que fazer algo genérico demais pra se encaixar em todas as situações levaria muito tempo e é complexo demais. Talvez pensar em algo mais específico pra sua squad/time. Se você realmente precisa de todas as tabelas, aí complica um pouco, mas se não precisa, procura usar só o que realmente importa pra você. Em relação ao que o nosso amigo @eliaseas disse aqui (e realmente é importante pensar nesses dados sensíveis), incluir nesse script algo que altere as colunas sensíveis (colocar valores fictícios) pode ser uma boa também pra não precisar fazer um registro 100% fake.

Outras coisas que encontrei

Dependendo da base que vc usa, tem recursos bons pra fazer o que vc ta querendo. O Postgres mesmo tem um recurso chamado "logical replication" que basicamente serve pra fazer esse sync parcial. Você pode também usar um query com "COPY" pra selecionar o que vc quer exportar exatamente (e.g. COPY (SELECT * FROM table WHERE condition) TO '/path/to/file.csv' WITH CSV;).