Notion: O Modelo de Blocos e o Sharding do Postgres

A decisão de modelagem mais fundamental do Notion é também a mais arriscada do ponto de vista de banco de dados: tudo é um bloco. Páginas, parágrafos, imagens, tabelas, bullet points, bancos de dados embutidos, todos são linhas na mesma tabela block. Cada bloco tem um id UUID, um type, um campo properties JSONB com conteúdo variável, e ponteiros para parent_id e space_id (o workspace). A hierarquia do documento inteiro é uma árvore de adjacência dentro dessa tabela única.

Essa escolha tem elegância real. O modelo de dados é uniforme, o código da aplicação lida com um único tipo de entidade, e funcionalidades como mover um bloco entre páginas ou tipos são triviais, você só atualiza o parent_id. Não há migrações de schema para novos tipos de conteúdo; você apenas adiciona um novo valor de type e popula properties de forma diferente.

Mas a elegância tem um custo direto em escala. Uma única tabela acumulando todos os conteúdos de todos os usuários cria uma superfície de contenção enorme. Índices crescem sem controle. O autovacuum do Postgres, o processo de fundo que recupera espaço de linhas mortas e atualiza estatísticas, começa a lutar contra o volume de writes. Operações DDL (como adicionar um índice) bloqueiam ou levam horas. E o mais crítico: o Postgres não tem sharding nativo. Toda a carga vai para uma instância primária, e escalar verticalmente tem um teto claro, tanto em custo quanto em latência de replicação.

Antes da migração, o Notion operava com uma arquitetura relativamente convencional para um SaaS em crescimento: uma aplicação Node.js/TypeScript conectada a um Postgres primário via PgBouncer para pooling de conexões, com read replicas para queries de leitura intensiva. O PgBouncer era essencial: Postgres tem um custo não trivial por conexão (memória, contexto de processo), e aplicações modernas com dezenas de instâncias de servidor facilmente saturam o banco com milhares de conexões simultâneas.

O problema de conexões foi o primeiro sinal visível de crise. Com crescimento acelerado em 2020, o número de instâncias de aplicação aumentou, e mesmo com PgBouncer, o banco primário começou a atingir limites. Mas o problema mais profundo era de throughput e latência de escrita. A tabela block recebia writes de altíssima frequência, cada keystroke de cada usuário pode gerar uma ou mais linhas novas ou atualizações. Com milhões de usuários ativos, isso se traduz em dezenas de milhares de writes por segundo, todos disputando locks na mesma tabela, nos mesmos índices.

O autovacuum é um ponto que merece atenção especial. No Postgres, quando você atualiza uma linha, a versão antiga não é deletada imediatamente, ela fica como 'dead tuple' até o vacuum passar. Em tabelas de alta escrita, o acúmulo de dead tuples degrada performance de leitura (os índices ficam inchados, os sequential scans ficam mais lentos) e pode, em casos extremos, causar transaction ID wraparound: um evento catastrófico que força o banco a parar de aceitar writes até que o vacuum complete. O Notion claramente estava se aproximando de condições onde o autovacuum não conseguia manter o ritmo.

A estratégia do Notion foi inteligente na sequência: primeiro introduzir sharding lógico sem mover dados, depois migrar fisicamente. Isso é o padrão correto para migrações de banco de dados em produção, você separa o problema de modelagem do problema de migração.

Fase 1: Sharding Lógico: A aplicação passa a tratar cada workspace_id como pertencente a um shard lógico. Um mapa de shards (uma tabela simples, cacheada em memória) mapeia workspace_id → shard_id. Toda query passa pelo shard router, que resolve o shard correto antes de abrir conexão. Nesse ponto, todos os shards lógicos ainda apontam para o mesmo banco físico, o comportamento muda, mas os dados não se movem. Isso permite testar o roteamento em produção sem risco de perda de dados.

Fase 2: Migração Física com Dupla Escrita: Para mover workspaces para novos shards físicos, o Notion usou o padrão clássico de dupla escrita (dual-write) com backfill. O processo: (a) começar a escrever em ambos os bancos (origem e destino) para novos eventos; (b) backfill dos dados históricos no destino; (c) verificar consistência; (d) redirecionar leituras para o destino; (e) parar de escrever na origem. Cada etapa é reversível. O risco de cada cutover é limitado ao conjunto de workspaces sendo migrados, não ao sistema inteiro.

A chave da escolha de workspace_id como shard key: Toda query do Notion inclui o contexto do workspace, um usuário sempre está operando dentro de um workspace específico. Isso significa que o shard key está naturalmente presente em todas as operações, e não há queries cross-shard no caminho crítico. Isso é fundamental: sharding só funciona bem quando você consegue garantir que a grande maioria das queries toca um único shard. O modelo de blocos do Notion, com sua hierarquia contida dentro de um workspace, torna isso natural.

O que não é resolvido pelo sharding: queries analíticas que precisam agregar dados de múltiplos workspaces (ex: métricas de produto, dashboards internos) agora requerem fan-out para todos os shards ou uma pipeline de dados separada. Esse é o trade-off aceito, você otimiza para o caminho crítico transacional e aceita complexidade no analítico.