Habilidades Database Architect
🏛️

Database Architect

Seguro

Projetar arquiteturas de banco de dados escaláveis

Escolher o banco de dados errado ou um design de schema inadequado leva a retrabalho custoso e problemas de performance. Esta skill oferece orientação especializada em seleção de tecnologias de banco de dados, modelagem de dados e design de arquitetura para construir camadas de dados escaláveis desde o início.

Suporta: Claude Codex Code(CC)
🥉 72 Bronze
1

Baixar o ZIP da skill

2

Upload no Claude

Vá em Configurações → Capacidades → Skills → Upload skill

3

Ative e comece a usar

Testar

A utilizar "Database Architect". Projete um schema para uma plataforma de blog com usuários, posts, comentários e tags.

Resultado esperado:

O schema recomendado inclui: tabela users (id, email, created_at), tabela posts com foreign key para users, tabela comments com parent_id auto-referencial para threading, tabela tags com tabela de junção many-to-many post_tags. Índices em posts.user_id, comments.post_id e índice full-text em posts.title e content.

A utilizar "Database Architect". Devo usar Redis ou PostgreSQL para armazenamento de sessão?

Resultado esperado:

Use Redis para armazenamento de sessão quando precisar de acesso rápido, expiração automática via TTL e escalabilidade horizontal. Use PostgreSQL quando as sessões precisarem sobreviver a reinícios do Redis, requererem queries complexas ou precisarem participar de transações de banco de dados. Para a maioria das aplicações web, Redis com persistência PostgreSQL oferece o melhor equilíbrio.

Auditoria de Segurança

Seguro
v1 • 2/24/2026

Static analysis scanned 0 files with risk score 0/100. Evaluation confirms this is a prompt-only skill with no executable code. The skill provides database architecture guidance through instructional text only. No dangerous patterns, network access, or code execution vectors detected. Safe for publication.

0
Arquivos analisados
0
Linhas analisadas
0
achados
1
Total de auditorias
Nenhum problema de segurança encontrado
Auditado por: claude

Pontuação de qualidade

38
Arquitetura
100
Manutenibilidade
87
Conteúdo
50
Comunidade
100
Segurança
74
Conformidade com especificações

O Que Você Pode Construir

Design de Plataforma Greenfield

Projetar uma arquitetura completa de banco de dados para uma nova plataforma SaaS incluindo seleção de tecnologia, design de schema e estratégia de scaling.

Planejamento de Migração de Banco de Dados

Criar um plano de migração detalhado para mover de um banco de dados MySQL monolítico para uma arquitetura de microsserviços com persistência poliglota.

Design de Schema NoSQL

Projetar schemas de documentos e padrões de acesso para um dashboard de analytics de alta velocidade usando MongoDB ou DynamoDB.

Tente Estes Prompts

Seleção Básica de Tecnologia 
Estou construindo uma nova aplicação que precisa armazenar perfis de usuário, transações e logs de atividade. A aplicação espera 10.000 usuários ativos diariamente inicialmente. Me ajude a escolher a tecnologia de banco de dados certa e explique os trade-offs.
Solicitação de Design de Schema 
Projete um schema de banco de dados para uma ferramenta de gerenciamento de projetos multi-tenant. Cada tenant tem usuários, projetos, tarefas e comentários. Mostre as tabelas, relacionamentos e índices chave necessários.
Planejamento de Estratégia de Migração 
Precisamos migrar de uma única instância MySQL para uma arquitetura sharded suportando 100M+ registros. Crie um plano de migração com zero downtime com fases, procedimentos de rollback e critérios de sucesso.
Arquitetura CQRS Avançada 
Projete uma arquitetura CQRS com event sourcing para um sistema de gerenciamento de pedidos. Inclua design do event store, projeções de read model, estratégias de snapshot e como lidar com evolução de schema ao longo do tempo.

Melhores Práticas

  • Sempre entenda os padrões de acesso e requisitos de escala antes de selecionar a tecnologia de banco de dados
  • Comece normalizado, depois desnormalize seletivamente baseado em performance de queries medida
  • Planeje migrações com procedimentos de rollback automatizados e teste completamente em staging

Evitar

  • Escolher bancos de dados da moda sem entender a complexidade operacional
  • Sobrenormalizar workloads read-heavy causando operações excessivas de JOIN
  • Pular planejamento de backup e rollback antes de migrações para produção

Perguntas Frequentes

Qual banco de dados devo escolher para minha startup?
Comece com PostgreSQL para a maioria das aplicações. Ele lida bem com dados relacionais, suporta JSON para flexibilidade e escala para milhões de usuários. Mude para bancos de dados especializados apenas quando tiver necessidades específicas como dados time-series, relacionamentos em grafo ou throughput massivo de escrita.
Como sei quando devo fazer sharding no meu banco de dados?
Considere sharding quando o scaling vertical se tornar proibitivamente custoso, o throughput de escrita exceder a capacidade de um único nó, ou o volume de dados impactar janelas de backup e manutenção. Primeiro otimize com read replicas, caching e otimização de queries antes de fazer sharding.
Devo usar um ORM ou escrever SQL puro?
Use ORMs como Prisma ou SQLAlchemy para operações CRUD e type safety. Escreva SQL puro para queries analíticas complexas, operações em bulk ou quando o ORM gerar queries ineficientes. Muitas equipes usam ambos: ORM para operações padrão e SQL puro para paths críticos de performance.
Como projeto para multi-tenancy?
Três abordagens existem: schema compartilhado com coluna tenant_id (mais simples), schema separado por tenant (melhor isolamento) ou banco de dados separado por tenant (máximo isolamento). Comece com schema compartilhado e tenant_id. Evolua para schemas ou bancos de dados separados para requisitos de compliance ou clientes enterprise de alto valor.
Qual estratégia de indexação devo usar?
Indexe colunas usadas em cláusulas WHERE, condições de JOIN e declarações ORDER BY. Use índices compostos para queries multi-coluna com a coluna mais seletiva primeiro. Monitore logs de slow query para identificar índices faltantes. Evite excesso de indexação em tabelas write-heavy pois cada índice adiciona overhead de escrita.
Como posso migrar com zero downtime?
Use o padrão expand-contract: primeiro adicione novo schema junto com o antigo (expand), migre dados incrementalmente com dual writes, verifique consistência, mude reads para o novo schema, então remova o schema antigo (contract). Sempre tenha procedimentos de rollback e teste a migração completa em staging.

Detalhes do Desenvolvedor

Autor

sickn33

Licença

MIT

Repositório

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/database-architect

Referência

main

Estrutura de arquivos

📄 SKILL.md