Herdr UI
Herdr의 TUI가 뛰어나며, 창을 통해 추가되는 기능
두 SQL 환경을 메모리 내 Postgres 인스턴스로 비교해 차이점을 정확히 보고, 마이그레이션 회귀를 사전에 탐지합니다
Runs the same query probes against two SQL setups on isolated in-memory Postgres instances and reports exactly what differs -- catches migration regressions before they touch a real database.
개발 도구TypeScriptGitHub @jayblast-spec온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Diffs two SQL setups' query results on isolated in-memory Postgres instances (via PGlite) -- catches migration regressions before they touch a real database.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Runs the same query probes against two SQL setups (e.g. two versions of a migration) on isolated in-memory Postgres instances and reports exactly what differs — catches migration regressions before they touch a real database.README 전문 보기 ↗Runs the same query probes against two SQL setups (e.g. two versions of a migration) on isolated in-memory Postgres instances and reports exactly what differs — catches migration regressions before they touch a real database.
PGlite — real PostgreSQL compiled to WASM, no Docker, no external service — has made "spin up a real Postgres in a test" fast enough to do per-test rather than per-CI-run. The pattern of using it to validate a single migration against seed data is already common. What's missing is the comparative version: when you refactor a migration history (squash old migrations, rewrite one for performance, reorder them), the risky question isn't "does the new migration run," it's "does it produce exactly the same query-visible results as what it replaced?" The existing open-source Postgres migration tools (Flyway, Liquibase, Atlas, Sqitch, pgroll, graphile-migrate, pgschema) all handle applying migrations; none of them diff two migration paths' resulting data against each other.
import { diffScenarios } from "pglite-diff";
const report = await diffScenarios(
{ setup: originalMigrationSql },
{ setup: refactoredMigrationSql },
[
{ name: "subscription pricing", sql: "select plan, monthly_price, annual_price from subscriptions order by id" },
{ name: "active users", sql: "select id, email from users where active order by id" },
]
);
if (!report.ok) {
console.error(JSON.stringify(report, null, 2));
process.exit(1);
}
Each scenario's setup SQL (schema + migrations + seed data, however you assemble it) runs against its own isolated in-memory PGlite instance. Every probe query then runs against both, and results are compared row-by-row, column-by-column. The report tells you exactly which probe found a difference, which row, which columns changed, and the before/after values — or, if a probe query itself fails on one side (e.g. a renamed column), that's reported distinctly rather than silently swallowed.
Overall: REGRESSION DETECTED
Probe "subscription pricing": MISMATCH
row 0: changed columns [annual_price]
before: {"plan":"starter","monthly_price":"10","annual_price":"96.0"}
after: {"plan":"starter","monthly_price":"10","annual_price":"108.0"}
- uses: jayblast-spec/pglite-diff@main
with:
config: ./pglite-diff.config.mjs
Or directly:
npx pglite-diff ./pglite-diff.config.mjs
Where the config file default-exports { before, after, probes }:
// pglite-diff.config.mjs
export default {
before: { setup: `/* schema + migrations + seed data, as they are today */` },
after: { setup: `/* schema + migrations + seed data, after your change */` },
probes: [
{ name: "pricing", sql: "select plan, annual_price from subscriptions order by id" },
],
};
npm install --save-dev pglite-diff @electric-sql/pglite
ORDER BY has no guaranteed row order in Postgres — write your probes with ORDER BY for deterministic, meaningful diffs. This is a deliberate simplicity choice, not an oversight: set-based comparison would hide genuinely meaningful ordering regressions (e.g. a broken ORDER BY clause) behind a false "no diff."before/after) failed to even build, so a broken migration doesn't get misreported as "every probe found a difference."npx tsx examples/demo.ts
information_schema — two schemas that produce identical query results for your probes are treated as equivalent, which is usually what you actually care about.npm install
npm run typecheck
npm test
npm run build
MIT
This is one of 8 independent open-source infrastructure tools, each built against a real, researched gap:
Built by ArkNet Digital.