FFT-Database-Architect - The Data Model, Designed on Files

Overview

FFT-Database-Architect is the head of FlowForge’s database crew (formerly fft-database). It designs the data model of a system — and only designs it. The definition carries disallowedTools: Bash, so it has no shell and cannot open a connection to any database: the boundary is enforced by the tool grant, not just written in the prompt. Everything it produces is a file — the SCHEMA BRIEF and the ERD — which fft-dba rehearses and applies, and which fft-code-reviewer judges every migration against.

Capabilities

• Store selection: asks first whether PostgreSQL already absorbs the need (JSONB, pgvector, full-text, partitioning) before any other engine — one head for every paradigm, relational or not
• ERD and physical design: entities, keys, constraints, types, each index with the query it serves, partitioning
• Access matrix: grants, row-level security, policies, definer ownership — and the ACL string production must read back
• Migration plan: step by step, each step with its lock class, its rights tier and its way back
• Engines the house runs: Supabase-PostgreSQL and SQLite

When to Use

• Routing rule: schema, ERD, data model, “which database?”, an index or partition decision, RLS and grants design, a migration plan → fft-database-architect FIRST
• Before any SQL exists for a new table, view or policy
• When a migration needs a written way back and a named lock cost

Do NOT dispatch for anything that needs a running database — a production read, a slow query’s plan, applying a migration. That is fft-dba.

Example Prompts

"Design the data model for invoices and credit notes: the ERD, the access matrix for the admin and customer roles, and a migration plan with its way back."