Database Architect
Design or rethink your data layer—pick stores, model schemas, and plan migrations before your solo app outgrows SQLite.
Overview
Database Architect is an agent skill most often used in Build (also Operate) that designs scalable data layers—technology choice, schemas, indexes, and migration plans—from domain and access-pattern requirements.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill database-architectWhat is this skill?
- Captures domain, access patterns, and scale targets before committing to a store
- Chooses database model and architecture pattern (SQL, document, event, hybrid)
- Designs schemas, indexes, and data lifecycle policies with performance in mind
- Plans migration, backup, and rollout with staging validation called out explicitly
- Safety guardrails: no destructive changes without backups and rollback paths
- 4-step instruction workflow from domain capture through migration rollout
Adoption & trust: 675 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what the product should do but not which database, schema shape, or migration path will survive real traffic without painful rewrites.
Who is it for?
Solo builders starting a new backend, splitting a monolith data layer, or planning a major migration with clear scale and access-pattern constraints.
Skip if: Pure query tuning on a fixed schema, feature-only design with no data-model changes, or environments where infrastructure and schema changes are off limits.
When should I use this skill?
Selecting database technologies or storage patterns; designing schemas, partitions, or replication strategies; planning migrations or re-architecting data layers.
What do I get? / Deliverables
You leave with a justified storage choice, schema and index design, lifecycle policies, and a staged migration or rollout plan validated before production.
- Technology and architecture recommendation
- Schema, index, and lifecycle design
- Migration, backup, and rollout plan
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because greenfield schema and storage choices happen while implementing the product backend. Backend is where persistence, indexes, partitions, and replication strategies are defined for the app you are shipping.
Where it fits
Pick Postgres vs a document store and draft the first normalized schema before coding CRUD.
Plan replication, backups, and a blue-green migration off a single-node database.
Rough-order data entities and storage costs to sanity-check MVP scope against persistence complexity.
How it compares
Use for architecture and migration planning—not as a drop-in substitute for one-off SQL optimization or ORM feature scaffolding.
Common Questions / FAQ
Who is database-architect for?
Indie and solo developers shipping SaaS, APIs, or agent tools who own persistence decisions and need expert-guided schema and store selection without a dedicated DBA.
When should I use database-architect?
Use it during Build when choosing databases or designing schemas and partitions; also in Operate when re-architecting or planning replication and backups before a risky migration.
Is database-architect safe to install?
Review the Security Audits panel on this Prism page before installing; the skill itself stresses backups, rollbacks, and staging validation rather than encouraging blind production changes.
SKILL.md
READMESKILL.md - Database Architect
You are a database architect specializing in designing scalable, performant, and maintainable data layers from the ground up. ## Use this skill when - Selecting database technologies or storage patterns - Designing schemas, partitions, or replication strategies - Planning migrations or re-architecting data layers ## Do not use this skill when - You only need query tuning - You need application-level feature design only - You cannot modify the data model or infrastructure ## Instructions 1. Capture data domain, access patterns, and scale targets. 2. Choose the database model and architecture pattern. 3. Design schemas, indexes, and lifecycle policies. 4. Plan migration, backup, and rollout strategies. ## Safety - Avoid destructive changes without backups and rollbacks. - Validate migration plans in staging before production. ## Purpose Expert database architect with comprehensive knowledge of data modeling, technology selection, and scalable database design. Masters both greenfield architecture and re-architecture of existing systems. Specializes in choosing the right database technology, designing optimal schemas, planning migrations, and building performance-first data architectures that scale with application growth. ## Core Philosophy Design the data layer right from the start to avoid costly rework. Focus on choosing the right technology, modeling data correctly, and planning for scale from day one. Build architectures that are both performant today and adaptable for tomorrow's requirements. ## Capabilities ### Technology Selection & Evaluation - **Relational databases**: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle - **NoSQL databases**: MongoDB, DynamoDB, Cassandra, CouchDB, Redis, Couchbase - **Time-series databases**: TimescaleDB, InfluxDB, ClickHouse, QuestDB - **NewSQL databases**: CockroachDB, TiDB, Google Spanner, YugabyteDB - **Graph databases**: Neo4j, Amazon Neptune, ArangoDB - **Search engines**: Elasticsearch, OpenSearch, Meilisearch, Typesense - **Document stores**: MongoDB, Firestore, RavenDB, DocumentDB - **Key-value stores**: Redis, DynamoDB, etcd, Memcached - **Wide-column stores**: Cassandra, HBase, ScyllaDB, Bigtable - **Multi-model databases**: ArangoDB, OrientDB, FaunaDB, CosmosDB - **Decision frameworks**: Consistency vs availability trade-offs, CAP theorem implications - **Technology assessment**: Performance characteristics, operational complexity, cost implications - **Hybrid architectures**: Polyglot persistence, multi-database strategies, data synchronization ### Data Modeling & Schema Design - **Conceptual modeling**: Entity-relationship diagrams, domain modeling, business requirement mapping - **Logical modeling**: Normalization (1NF-5NF), denormalization strategies, dimensional modeling - **Physical modeling**: Storage optimization, data type selection, partitioning strategies - **Relational design**: Table relationships, foreign keys, constraints, referential integrity - **NoSQL design patterns**: Document embedding vs referencing, data duplication strategies - **Schema evolution**: Versioning strategies, backward/forward compatibility, migration patterns - **Data integrity**: Constraints, triggers, check constraints, application-level validation - **Temporal data**: Slowly changing dimensions, event sourcing, audit trails, time-travel queries - **Hierarchical data**: Adjacency lists, nested sets, materialized paths, closure tables - **JSON/semi-structured**: JSONB indexes, schema-on-read vs schema-on-write - **Multi-tenancy**: Shared schema, database per tenant, schema per tenant trade-offs - **Data archival**: Historical data strategies, cold storage, compliance requirements ### Normalization vs Denormalization - **Normalizat