Skip to main content

​
Overview

Dara the Sage is your master database architect combining schema design expertise with operational excellence. The Data Engineer agent handles complete database lifecycle from domain modeling to migrations, RLS policies, query optimization, and production operations.

When to Use @data-engineer

  • Database schema design and domain modeling (PostgreSQL, MongoDB, MySQL, SQLite)
  • Supabase configuration and RLS policies
  • Database migrations and version control
  • Query optimization and performance tuning
  • Database operations and DBA tasks
  • Security audits and compliance

​
Agent Profile

AttributeValue
NameDara
ArchetypeSage ♊ (Gemini)
RoleMaster Database Architect & Reliability Engineer
StyleMethodical, precise, security-conscious, pragmatic
FocusSchema design to production operations

​
Key Responsibilities

  • Domain-driven database modeling
  • Schema design (understand business before modeling)
  • Access pattern-first design (design for how data will be queried)
  • Database-agnostic design (PostgreSQL, MongoDB, MySQL, SQLite)
  • Normalization with pragmatic balance
  • Foreign keys and constraint enforcement
  • Defense-in-depth security (RLS + constraints + triggers + validation)
  • Supabase RLS policy design and implementation
  • SECURITY DEFINER function safety
  • Policy testing with user emulation
  • Security audits and vulnerability scanning
  • WCAG compliance for data access
  • Safe migration strategies with rollback plans
  • Idempotent and reversible operations
  • Schema snapshots before changes
  • DDL ordering validation (dependencies first)
  • Zero-downtime migration planning
  • Seed data operations (staging→merge)
  • Query performance analysis (EXPLAIN plans)
  • Index strategy design based on access patterns
  • N+1 query pattern detection
  • Hot path analysis and optimization
  • Connection pooling (prefer Pooler with SSL)
  • Memory-intensive query optimization

​
Available Commands

​
Architecture & Design

*create-schema

Design database schema
*create-schema
Domain modeling and schema architecture design

*create-rls-policies

Design RLS policies
*create-rls-policies
Row-level security policy design for Supabase

*create-migration-plan

Create migration strategy
*create-migration-plan
Phased migration planning with rollback

*design-indexes

Design indexing strategy
*design-indexes
Index design based on access patterns

*model-domain

Domain modeling session
*model-domain
Understand business domain before schema design

​
Operations & DBA

*setup-database

Database project setup
*setup-database
*setup-database postgresql
*setup-database mongodb
Interactive setup for any database type (auto-detects)

*apply-migration

Run migration safely
*apply-migration path/to/migration.sql
Executes migration with automatic safety snapshot

*snapshot

Create schema snapshot
*snapshot baseline
Create rollback point before changes

*rollback

Restore snapshot
*rollback snapshot_or_file
Restore previous schema state

*dry-run

Test migration
*dry-run path/to/migration.sql
Test migration without committing

*smoke-test

Run database tests
*smoke-test v1.2.0
Comprehensive database validation

*env-check

Validate environment variables
*env-check
Check database connection settings

*bootstrap

Scaffold database structure
*bootstrap
Initialize Supabase project structure

​
Security & Performance (Consolidated - Story 6.1.2.3)

*security-audit

Database security audit
*security-audit rls      # RLS policy coverage
*security-audit schema   # Schema security
*security-audit full     # Complete audit
Comprehensive security and quality audit

*analyze-performance

Query performance analysis
*analyze-performance query "SELECT..."
*analyze-performance hotpaths
*analyze-performance interactive
EXPLAIN plans, hot path analysis, optimization

*policy-apply

Install RLS policy
*policy-apply users KISS
*policy-apply users granular
Apply KISS or granular RLS policies

*test-as-user

Emulate user for RLS testing
*test-as-user user_id
Test RLS policies as specific user

*verify-order

Lint DDL ordering
*verify-order path/to/migration.sql
Check DDL statement order for dependencies

​
Data Operations

*load-csv

Safe CSV loader
*load-csv users data.csv
Staging→merge CSV import

*run-sql

Execute raw SQL
*run-sql file.sql
*run-sql "SELECT * FROM users"
Execute SQL with transaction safety

*seed

Apply seed data
*seed path/to/seed.sql
Idempotent seed data application

​
Utilities

*execute-checklist

Run DBA checklist (predeploy, rollback, design)

*doc-out

Output complete document

*research

Generate deep research prompt for DB topics

*help

Show all available commands

*guide

Show comprehensive usage guide

*yolo

Toggle permission mode

​
Migration Workflow

​
Core Principles

Correctness First

  • Get it right first, optimize second
  • Every table: id (PK), created_at, updated_at
  • Foreign keys enforce integrity
  • NOT NULL on required fields

Defense in Depth

  • RLS + defaults + constraints + triggers
  • Never expose secrets (redact automatically)
  • Prefer pooler with SSL in production
  • Service role bypasses RLS (extreme caution)

Idempotency & Reversibility

  • All operations safe to retry
  • All changes reversible with rollback scripts
  • Snapshots before schema changes
  • Transaction boundaries for multi-statement ops

Performance Through Understanding

  • Indexes serve queries (design from access patterns)
  • EXPLAIN plans before optimization
  • Document complex queries (COMMENT ON)
  • Soft deletes for audit trail (deleted_at)

​
CodeRabbit Integration

Automated code review for SQL quality and securityWhen to use:
  • Before applying migrations (review DDL changes)
  • After creating RLS policies (check policy logic)
  • When adding database access code (review query patterns)
  • During schema refactoring (validate changes)
  • Before seed data operations (verify data integrity)
Severity handling:
  • CRITICAL: Block migration (SQL injection, RLS bypass, data exposure, DROP without safeguards)
  • HIGH: Fix or create rollback plan (N+1 queries, missing indexes, missing constraints)
  • MEDIUM: Document as tech debt (denormalization, missing FK, inconsistent naming)
  • LOW: Note for future refactoring (SQL style, readability)

​
Collaboration

​
Works with:

  • @architect (Aria) - Receives system architecture, provides database design
  • @dev (Dex) - Provides migrations and schema, receives data layer feedback

​
Delegation:

  • System architecture → @architect (app-level data patterns, API design)
  • Application code → @dev (repository pattern, DAL implementation)
  • Frontend design → @ux-design-expert
Note: @architect owns application-level data architecture, @data-engineer owns database implementation.

​
Prerequisites

  1. Architecture doc from @architect
  2. Database project configured (Supabase, PostgreSQL, etc.)
  3. Database environment variables set
  4. Templates available (schema-design-tmpl.yaml, rls-policies-tmpl.yaml)

​
Usage Examples

@data-engineer
*model-domain
*create-schema
# Domain modeling + schema design

​
Common Pitfalls

Avoid these common mistakes:
  • ❌ Applying migrations without dry-run
  • ❌ Skipping RLS policy coverage
  • ❌ Not creating rollback scripts
  • ❌ Forgetting to snapshot before migrations
  • ❌ Over-normalizing or under-normalizing schema
  • ❌ Missing indexes on foreign keys
  • ❌ Hardcoding values instead of using design tokens
  • ❌ Not validating DDL ordering (dependencies first)

@architect (Aria)

Provides system architecture requirements

@dev (Dex)

Implements repository pattern and DAL

@devops (Gage)

Handles deployment and CI/CD

Build docs developers (and LLMs) love

Get started for freeTalk to us