CDC multi-tenant: guia de arquitetura SaaS com um banco de dados por tenant

O guia da Estuary parte de uma restrição do PostgreSQL: cada slot de replicação lê as mudanças de um único banco. Em SaaS com um banco por tenant, isso obriga a ter um slot e uma captura por tenant. Cada captura marca os documentos com uma tag de origem (em /_meta/source/tag), e todas escrevem na mesma coleção compartilhada por tabela. Uma única materialização leva isso ao destino, com chave composta por tag mais chave primária.

O ponto central é a colisão de chaves. Tenants reusam valores de chave primária, então chavear o destino só por id faz um tenant sobrescrever (ou apagar) a linha de outro. No teste, a materialização em PostgreSQL rejeitou a tag como chave porque a descoberta a marca como opcional. A correção foi exigir a tag no schema de leitura da coleção. O guia também recomenda manter a tag fora da chave da coleção de captura, já que ela não é coluna da tabela de origem e a captura usa essa chave para paginar o backfill.

Os limites operacionais vêm do servidor: cada tenant consome um slot e um WAL sender (max_replication_slots e max_wal_senders, padrão 10). Os nomes de slot são únicos no servidor, e o padrão flow_slot fez uma segunda captura falhar no teste. Um slot parado segura WAL de todos os tenants no mesmo servidor. A recomendação é desligar a adição automática de coleções, rodar o onboarding por CI e monitorar cada captura e o WAL retido por slot, não só a frescor agregada do destino. O teste usou poucos tenants e não mede escala.

A cobertura anterior toca o mesmo território de PostgreSQL e CDC, mas não acompanha este guia como evolução do mesmo produto. Em 15 de setembro de 2026, o CEVIU noticiou "Desafios e Soluções para Backfills de CDC em Larga Escala no PostgreSQL", que já apontava retenção de WAL como gargalo. O guia atual aplica essa preocupação ao cenário multi-tenant, em que um slot parado em um tenant pode encher o disco compartilhado. Em 12 de outubro de 2026, a matéria "Migrações de Schema em PostgreSQL sem Downtime: Estratégias Essenciais para Produção" tratou de mudanças de schema em produção. O guia da Estuary conecta isso ao CDC ao recomendar mudanças aditivas, pois uma coluna nova em um tenant pausou brevemente a entrega para todos no teste.

Para quem opera analytics sobre bancos por tenant, a lição é tratar a chave composta e o monitoramento por captura como requisitos de projeto, não ajustes posteriores. Na leitura do CEVIU, o risco mais fácil de ignorar é o compartilhado: o isolamento vale para as capturas, mas materialização, coleções e disco do servidor continuam sendo ponto único de falha.