Additive change
Safe
No supported incompatibility was detected under the conditions tested. This is not a universal safety guarantee.
Adds a nullable column, a new table and a plain index. Nothing the old version does can notice.
Recorded example: genuine engine output generated Sat, 24 Oct 2026 18:29:54 GMT from the committed fixture. Run it again live below.
Baseline schema
Proposed schema
Previous versionshop-v1
2/2 test files passno database errors
2/2 test files passno database errors, identical in all 2 runs
Current versionA-safe-additive
Not needed: ordinary CI covers this
Not configured
The outlined cell is the compatibility question. The verdict comes only from it, compared against the cell to its left.
Next step
Proceed with normal review. Keep the old application's tests meaningful; SAFE only covers what they exercise.
Starts a throwaway PostgreSQL and runs the full experiment, usually in under 15 seconds.
Schema changes
All 3 schema change(s) are additive and cannot affect statements the old application issues; no coverage is required.
| Change | Risk to old statements | Exercised by previous version |
|---|---|---|
| Relation audit_log added | inert | Not required |
| Column customers.loyalty_tier added (text) | inert | Not required |
| Index orders_created_at_idx added on orders | inert | Not required |
Runs
Proposed migration: 002_loyalty.sql · PostgreSQL 16.15 (Debian 16.15-1.pgdg12+2) · gate does not block (exit 0)
| Run | Migrations | Test files | Database errors | Statements logged |
|---|---|---|---|---|
| control (old app × baseline schema) | 1/1 | 2/2 pass | 0 | 7 |
| candidate #1 (old app × proposed schema) | 2/2 | 2/2 pass | 0 | 7 |
| candidate #2 (old app × proposed schema) | 2/2 | 2/2 pass | 0 | 7 |
Download this report: JSONMarkdownJUnit XML
What this result does not cover
- Current application × proposed schema (no current app configured).
- Performance / lock-time analysis (out of scope).
- Skewcheck only observes code paths that the old application's tests execute; untested paths are reported as coverage gaps, not as safe.
- Coverage is identifier-level: a statement "touches" a changed object when it names the table (and column, or uses *). It is not a SQL parser.
- Correlation between an error and a schema change uses a fixed set of deterministic rules (R1–R6). Anything else is reported as ADVISORY, never UNSAFE.
- Performance, locking and migration runtime on production-sized data are not evaluated.
- Test files of one run share a database and run sequentially; ordering effects are identical across runs but are not isolated.
- Data-only migration effects are detected only when a test asserts on the affected data.