Your Test Data Is Type-Correct and Still Invalid: 6 Postgres Schema Features Generators Skip
TL;DR: Composite primary keys, partial unique indexes, cross-column CHECK constraints, JSONB shape, GENERATED ALWAYS columns, and row-level security all reject type-correct data, because column types are not what your schema actually enforces.
A few months ago I watched a seed run finish with a clean green summary: every column populated, every type correct, a few thousand rows inserted. The first integration test then failed on an INSERT the application itself ran. The generated data was valid the way a sentence with correct grammar can still be a lie. Each value matched its column type. The combination of values broke a constraint the generator never looked at.
That gap has a simple cause. A column type is a per-column promise: this is an integer, this is text, this is jsonb. Most of what a real schema enforces is not per-column. It lives one level up: across columns in a row, across rows in a table, or across the role doing the writing. A generator that thinks in columns produces data that is type-correct and still invalid.
Here are six places that gap shows up in Postgres, what each one actually enforces, and a query you can run to see whether your own generated data respects it.
