The AI Data Engineer for Databases and Pipelines

Database migrations are where good intentions go to die at 2 a.m. The column rename that seemed straightforward locks the table for forty seconds in production. The backfill that worked fine on the staging dataset with ten thousand rows runs for six hours on production with ten million. The NOT NULL constraint added to an existing column fails immediately because there are nulls already in the table, a fact nobody checked before writing the migration. These are not edge cases; they are the standard failure mode of database work done without someone who has seen these patterns before and knows how to route around them. The discipline of zero-downtime migrations, reversible steps designed to run while the application is serving traffic, is not complicated once you know it, but it is not what you get from a generalist AI tool that has not been taught to think about live production traffic. That discipline is what Flux exists to apply.

Why the generalist approach breaks down

Ask ChatGPT to add a column to a Postgres table and it will write an ALTER TABLE statement. Ask a data engineer to do the same thing and they will ask: how large is the table, is the application currently running, does the new column need a default value, and does that default value mean a full table rewrite? The ALTER TABLE statement is correct syntax. It is not a zero-downtime migration. On a table with fifty million rows, an ALTER TABLE ADD COLUMN NOT NULL DEFAULT 'pending' rewrites the entire table and holds a lock that blocks all reads and writes for the duration. The generalist tool does not know the difference. It produces the migration and stops.

Cursor and GitHub Copilot have a related problem with SQL: they complete queries without understanding the execution plan. A query that works correctly and returns the right data can still be disastrously slow if the WHERE clause is missing an index, if the join order is inefficient, or if a subquery is re-executed on every row in the outer query when it could be a single CTE. Autocomplete tools produce syntactically correct SQL. They do not produce queries that have been reviewed against the execution plan for the specific table sizes and index configuration of the production database. The difference between a 20ms query and a 20-second query is often a single index or a single rewrite, and finding it requires the kind of execution plan analysis that Cursor is not equipped to perform.

The data pipeline dimension is where the complexity fully surfaces. ETL and ELT pipelines that work correctly in development fail in production because nobody designed the error handling for partial failures, the dead letter queue for records that cannot be processed, or the idempotency mechanism that allows the pipeline to be re-run without producing duplicate records. These are not theoretical concerns, they are the standard failure modes of data pipelines built for the happy path. Generalist tools produce pipelines that work on the happy path and fail silently in production. Flux designs the unhappy paths first.

What a data engineer actually does

On a human engineering team, the data engineer owns the layer between raw data and the application and analytics systems that need it. They design database schemas with proper normalization for write-heavy paths and strategic denormalization for high-frequency read paths, not because normalization is a theoretical ideal but because it determines whether the write amplification at scale is acceptable. They write migrations that can be deployed to production with zero downtime, using the expand-contract pattern where necessary: add the new column, backfill it in batches, add the constraint only after the backfill completes. They build pipelines that handle failures gracefully: dead letter queues for records that fail processing, retry logic with backoff for transient failures, idempotency keys that prevent duplicate records from a pipeline re-run.

The data engineer is also the person who reads a slow query log and translates it into a prioritized optimization plan. They read execution plans and know what a sequential scan on a large table means (a missing index or a query rewrite opportunity), what a hash join versus a nested loop join means at different data sizes, and when a materialized view or a denormalized summary table is the right answer versus a query rewrite. That combination of schema design, migration safety, pipeline reliability, and query optimization expertise is the full stack of data engineering, and all of it is available through Flux.

Meet Flux

Flux is Tonone's data engineer, the specialist agent for database schema design, zero-downtime migrations, ETL and ELT pipelines, query optimization, and data health auditing. Flux's working philosophy is that data infrastructure is the layer everything else depends on, getting it wrong is expensive in ways that compound over time, and getting it right from the start is cheaper than fixing it after the schema has been in production for a year. Every schema Flux designs includes the reasoning behind its normalization decisions. Every migration Flux writes includes an explicit rollback plan.

Tonone's Flux designs database schemas with proper normalization, writes zero-downtime migrations with explicit rollback plans, and builds ETL pipelines with error handling and idempotency, data infrastructure done right from the start.

What Flux actually does

Designing database schemas with reasoning

The flux-schema skill is Flux's core design capability. You describe the domain, the entities, the relationships between them, the expected query patterns, and Flux produces a database schema with proper normalization for write paths, strategic denormalization for high-frequency read paths where the join cost would be prohibitive, indexes for the expected query patterns (not just primary keys, the composite indexes for the ORDER BY and WHERE clauses that production queries will actually execute), constraints that enforce data integrity at the database level (NOT NULL, UNIQUE, FOREIGN KEY, CHECK constraints), and migration files ready to run. The output explains the reasoning behind every design decision: why this table is normalized to 3NF, why this particular column is denormalized into a summary table, why this index is composite rather than single-column. That documentation is not for show, it is the institutional knowledge that prevents the next engineer from undoing a design decision that was made for a reason they cannot see in the schema itself. For teams starting a new service or redesigning an existing data model, flux-schema compresses the schema design process into a structured output that can be reviewed and challenged before any migrations are written.

Writing zero-downtime migrations

The flux-migrate skill is the capability that protects production databases during schema changes. Flux writes migrations using the expand-contract pattern, a sequence of reversible steps that can be applied while the application is running, each step safe for concurrent reads and writes during the migration window. For a column rename (one of the most common sources of production incidents), the safe approach is: add the new column, copy data from the old column in batches that do not hold a lock for more than a few milliseconds, update the application to write both columns simultaneously, remove the old column once all reads use the new column. Flux produces all of those steps, in order, with the rollback procedure for each step, what to do if the migration needs to be reversed at step two, at step three, at step four. For backfills on large tables, Flux produces batch backfill scripts that process a configurable number of rows at a time with a delay between batches, so the backfill does not starve the production database of I/O capacity. Index creation on large tables is done with CREATE INDEX CONCURRENTLY to avoid table locks. These are the migration patterns that distinguish zero-downtime deployments from planned maintenance windows.

Tonone's Flux flux-migrate skill writes zero-downtime database migrations using the expand-contract pattern, reversible steps safe for concurrent reads and writes, with an explicit rollback plan for every step.

Building reliable data pipelines

The flux-pipeline skill builds data pipelines from source to destination with the reliability characteristics that production pipelines require. Flux designs the extraction layer (reading from APIs, databases, or files with consistent handling of pagination and rate limits), the transformation layer (type coercion, deduplication, business logic applied consistently with test coverage), and the loading layer (writing to the target store with idempotency keys that prevent duplicate records from a re-run). The pipeline includes error handling for partial failures (individual records that cannot be processed are routed to a dead letter queue with the error reason captured, not silently dropped), retry logic with exponential backoff for transient failures (network timeouts, rate limit responses), and scheduled or event-driven execution depending on the latency requirements. The pipeline design distinguishes between ETL (transform before loading, appropriate for structured targets with strict schemas) and ELT (load raw data and transform in-place, appropriate for data warehouses with flexible query layers) and explains the tradeoff. For teams building analytics infrastructure or event-driven data products, flux-pipeline produces the data pipeline that actually works in production, not the one that works in development.

Optimizing slow queries

The flux-query skill takes a slow query and returns a faster one, with the execution plan analysis that explains why it is faster, not just the rewritten SQL. Flux reads the query, the table schema, and the available indexes, then generates the EXPLAIN ANALYZE output (or requests it if running in context), identifies the bottleneck (sequential scan on a table of ten million rows, inefficient join order, correlated subquery re-executed per row, sort without an index), and produces a rewritten query that addresses the root cause. Where an index would help more than a rewrite, Flux specifies the exact index to create, including column order for composite indexes (the column with the highest selectivity first, except when an ORDER BY alignment changes the calculus). Where a materialized view or summary table is the right architectural answer, Flux makes that recommendation with the specific tradeoff: the query goes from 8 seconds to 30 milliseconds but requires a refresh on a schedule that introduces staleness. The output is not just an optimized query, it is the explanation of why the original was slow, which gives the team the tools to avoid similar patterns in future queries.

Auditing data quality and pipeline health

The flux-health skill audits data quality and pipeline health across the dimensions that matter for production data infrastructure. Freshness: is the data in each table arriving within its expected SLA window, or are pipelines silently delayed without triggering alerts? Schema drift: are there differences between the schema in the staging and production environments that will cause the next migration to fail? Null rates: are columns that should never be null accumulating null values, indicating a data quality regression in an upstream pipeline? Orphaned records: do records exist in child tables without a corresponding parent, indicating missing foreign key constraints or failed cascade deletes? Pipeline execution: are all scheduled pipelines completing successfully, or are some silently failing and retrying indefinitely? The flux-health output is a data quality report that can be run on a schedule and used as the basis for a data quality SLA, a systematic check that the data infrastructure is behaving as expected, not just that it is running.

Tonone's Flux flux-health skill audits data freshness, schema drift between environments, null rates on constrained columns, orphaned records from missing FK constraints, and pipeline execution status, a complete data quality report.

A worked example

A team needs to rename the users.name column to users.display_name on a Postgres table with 8 million rows, with zero downtime. They hand Flux the brief. Flux produces the following migration, not a single ALTER TABLE RENAME COLUMN, but the full expand-contract sequence:

-- flux-migrate output, zero-downtime column rename: users.name → users.display_name
-- Table: users (~8M rows). Safe for concurrent reads/writes at each step.

-- ── STEP 1: Expand ────────────────────────────────────────────────────────────
-- Add the new column. No data moved yet. Application still reads/writes 'name'.
ALTER TABLE users ADD COLUMN display_name TEXT;
-- Rollback: ALTER TABLE users DROP COLUMN display_name;

-- ── STEP 2: Backfill (run in batches, do not run as a single statement) ───────
-- Process 10,000 rows at a time with pg_sleep(0.05) between batches.
-- Expected duration at 8M rows: ~90 minutes. No table lock.
DO $$
DECLARE
  batch_size INT := 10000;
  last_id    BIGINT := 0;
BEGIN
  LOOP
    UPDATE users
    SET    display_name = name
    WHERE  id > last_id
      AND  id <= last_id + batch_size
      AND  display_name IS NULL;

    EXIT WHEN NOT FOUND;
    last_id := last_id + batch_size;
    PERFORM pg_sleep(0.05);  -- yield I/O between batches
  END LOOP;
END $$;
-- Rollback: no-op (display_name dropped in step 1 rollback)

-- ── STEP 3: Add constraint (after backfill completes and app writes both cols) ─
ALTER TABLE users ALTER COLUMN display_name SET NOT NULL;
-- Rollback: ALTER TABLE users ALTER COLUMN display_name DROP NOT NULL;

-- ── STEP 4: Contract ──────────────────────────────────────────────────────────
-- Only after application reads display_name exclusively. Then drop old column.
ALTER TABLE users DROP COLUMN name;
-- Rollback: impossible after this step, take snapshot before running.

This is the migration a senior data engineer produces: four steps, each with a rollback, sequenced to ensure no step blocks production traffic. The NOT NULL constraint is deferred to step three because applying it in step one would fail immediately on a table with nulls already in the column. The batch backfill protects the I/O capacity of the database during the migration window. The comment on step four is the kind of operational note that prevents someone from running the rollback after the point of no return.

Flux vs the alternatives

Flux is not a query editor or a schema visualization tool, it is the data engineer who brings production experience to every decision about how data is stored, moved, and accessed. The comparison below captures where Flux differs from generalist tools when the stakes are a production database with real traffic.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Flux, are available in your Claude Code session.