1) Modelagem de dados: evitar anti-padrões desde o início

• Confiar apenas na validação no cliente. Sempre imponha constraints e Foreign Keys no Postgres para manter a integridade dos dados.
• Não definir tipos adequados. Use UUIDs para identificadores onde apropriado e timestamps com time zone (timestamptz) para data/hora.
• Evitar uso indiscriminado de JSONB sem índices. Use JSONB para dados semi-estruturados apenas se houver necessidade real, e crie índices nos campos acessados com frequência.
• Faltas comuns: tabelas sem chaves estrangeiras, ausência de índices em colunas filtradas, nomenclatura inconsistente de colunas-chave.

Boas práticas rápidas para começar: normalize onde faz sentido, mas utilize índices parciais quando apenas um subconjunto é consultado com frequência.

2) Controle de acesso com Row Level Security (RLS): políticas inconsistente causam vazamentos ou bloqueios

RLS é a linha de defesa que impede que usuários vejam dados que não deveriam. Muitas dores surgem quando:
RLS não está habilitado em tabelas sensíveis, políticas são omitidas ou permissões são muito permissivas.

Exemplos de políticas básicas para uma tabela de posts com owner_id:

-- Habilita RLS na tabela
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- Política: apenas o proprietário pode ler o post
CREATE POLICY "owner_read" ON posts FOR SELECT USING (auth.uid() = owner_id);

-- Política: proprietário pode atualizar o post, mantendo a verificação
CREATE POLICY "owner_update" ON posts FOR UPDATE USING (auth.uid() = owner_id) WITH CHECK (auth.uid() = owner_id);

Notas importantes:
– Sempre habilite RLS nas tabelas expostas a clientes.
– Use auth.uid() para mapear o usuário autenticado ao conteúdo.
– Combine FOR (SELECT|UPDATE|INSERT|DELETE) com USING e WITH CHECK para cobrir leitura e mutação.

3) Consultas, índices e padrões de paginação: evite N+1 e leituras caras

Desempenho costuma fugir quando não pensamos em índices, filtros e paginação correta. Dicas rápidas:

• Crie índices em colunas usadas em filtros, joins e ordenação frequentes (por exemplo, owner_id, created_at).
• Evite SELECT *; selecione apenas as colunas necessárias para reduzir tráfego de rede e uso de memória.
• Prefira paginação baseada em cursor (pagination via “created_at” ou “id”) em vez de offset, para manter desempenho em grandes conjuntos de dados.
• Considere views/materialized views para consultas caras que não exigem dados em tempo real.

Exemplos de consultas eficientes:

-- Lista posts de um usuário, ordenados por data, com paginação baseada em cursor
SELECT id, title, created_at
FROM posts
WHERE owner_id = $1
  AND (created_at < $2 OR (created_at = $2 AND id < $3))
ORDER BY created_at DESC, id DESC
LIMIT 20;

-- Índice recomendado para essa consulta
CREATE INDEX IF NOT EXISTS idx_posts_owner_created ON posts (owner_id, created_at DESC, id DESC);

4) Segurança, autenticação e operações de produção

• Não exponha keys de serviço ou chaves administrativas no frontend. Use o anon/public key apenas com permissões mínimas.
• Gerencie segredos com cuidado: utilize variables de ambiente, rotation de chaves e secrets vault quando possível.
• Separe ambientes (desenvolvimento, homologação, produção) para evitar impactos acidentais nas regras de acesso e nos dados.
• Ative logs de auditoria e monitore padrões de acesso para detectar atividades suspeitas rapidamente.

Princípio-chave: menos privilégio, menos superfície de ataque. Revise políticas de acesso periodicamente e teste cenários de falha com simulações controladas.