The conventions were settled: procedure skeletons, DECLARE banners, file naming, forbidden constructs — all versioned in rule files, every rule with its rationale. The only open question was which tool should check the SQL conventions. And the first reflex was the same one that probably surfaces in every Postgres team with convention ambitions: “Just use … Read more
Most data quality systems don’t die of bad checks. They die of a missing field in the rule model: the severity. A missing country code in three out of 80,000 rows blocks the nightly load, someone switches the check off “temporarily”, and from that moment everything runs unchecked. Steering data quality with severity levels instead of binary … Read more
The rule “country_code is mandatory” lives in your database twice: once as NOT NULL in the target table’s schema, and once as a hand-typed row in the check configuration. On the next ALTER TABLE, only one of the two places changes, and the check silently goes wrong. With derived data quality rules you no longer type that repetition: the metadata already … Read more
SQL Server or PostgreSQL — the question is rarely “which database is better?” but “which one fits your budget, your team and your platform?”. Whoever confuses the two questions migrates for the wrong reasons and only notices once the licensing bill shrinks while operating costs grow. Quick overview: Prerequisite: Hands-on SQL Server experience is all you … Read more
An empty repo and Claude Code, Anthropic’s coding agent in the terminal — that’s all it takes to get going. And that is exactly the problem: the model writes code immediately, but by default nothing ensures that a specification exists first, that a review happens afterwards, or that the database schema deploys reproducibly. A Claude … Read more
In many projects the database schema lives in the database instead of the repository — grown out of years of hand-run ALTERs, fully documented nowhere. It only becomes visible when a second environment is needed or a deploy breaks. Postgres database CI/CD flips that relationship: the repository describes the desired state, and every environment — from the throwaway … Read more
The bug was a typo in an ALTER TABLE — and it was found by the staging deploy on a Friday afternoon. Yet that exact find is automatable: set up a GitHub Actions Postgres deployment against a throwaway database, and every pull request becomes a full dress rehearsal. Syntax and semantic errors, ordering problems, and broken idempotency surface before … Read more
The backfill ran a second time on the second deploy — and overwrote values that had been corrected by the business in the meantime. Accidents like this are not prevented by discipline, only by a memory: if you want to track database schema changes without introducing Flyway or Liquibase, all it takes is exactly one table and … Read more
The ALTER TABLE ran through cleanly on your machine — on staging, the same deploy fails with column “country_code” of relation “customer” contains null values. The difference is not the SQL, it is the data: the local table was empty, the one on staging was not. If you want to add a NOT NULL column to an existing table that … Read more
The schema is done — now what? The reflex answer is Flyway or Liquibase. But for a small, database-centric project, a migration tool is often more machinery than the task calls for: its own version table, a runtime dependency, a file format you commit to. There is another way. Deploying a Postgres schema without a migration … Read more
