Postgres schema-per-service: o por que e o quando dói
Uma instância de Postgres, 15 schemas, 15 serviços. A defesa de uma escolha contra-intuitiva.
Microsserviços ortodoxos pregam 'um banco por serviço'. Camverly faz diferente: uma instância Postgres com um schema por serviço. Auth tem seu schema auth, tenancy tem tenancy, e por aí. A escolha foi consciente e contra-intuitiva, e tem motivos bem específicos. Mas a defesa só funciona se a gente também entenda onde o trade-off aparece como dívida.
Por que escolhemos: custo operacional. Um Postgres bem dimensionado roda 15 schemas pequenos com 95% menos overhead que 15 instâncias separadas. Backup é um único pg_dump (com filtros por schema, se necessário). Replicação é um único pg_basebackup. Monitoramento é uma única instância pra observar. Pra startup com cinco devs, isso é a diferença entre dedicar uma pessoa pra DBA full-time e dedicar 10% de uma pessoa.
Por que funciona apesar do isolamento ser fraco: enforcement por convenção + Row Level Security. Cada serviço se conecta com role própria, que só tem grant no seu schema. RLS adiciona uma camada extra onde site_id filtra rows automaticamente pra qualquer query. Se serviço A tenta query no schema do serviço B (acidentalmente ou maliciosamente), permissão é negada na conexão. Não é isolamento físico mas é prático.
Onde dói: migrations atômicas. Você quer adicionar um campo em auth.users que afeta como tenancy.sites valida algo. Em arquitetura com bancos separados, são duas migrations independentes coordenadas por aplicação. Com schema único, você pode fazer migration atômica — útil mas com vício oposto: tenta a tentação de fazer JOIN cross-schema, que é exatamente o que a arquitetura tentava evitar. A disciplina precisa ser cultural: jamais JOIN entre schemas em código.
O cenário onde voltaríamos atrás: quando workload de um serviço passar a dominar I/O da instância. Hoje cada schema tem footprint pequeno e o gargalo é network, não disco. Se posts crescer pra 100 milhões de rows e o workload de authoring estourar IOPS, vai valer separar essa instância. Mas é cenário de daqui a dois ou três anos. Por enquanto, o desenho economiza meses de DevOps e não nos prende em nenhuma dívida que não seja saneável depois.