Probably the most random section, where I detail projects or things I’ve worked on, be it private systems (with proper approval and clearance, and discretion) or open source projects.
Every ClickHouse migration tool I found makes you hand-write the DDL or learn a separate schema language. I wanted to declare MergeTree specifics in the models I already had, so I built that. Here is what it looks like, and where the other tools still win.
I built DBWarden, so I’m biased. This is my honest comparison with Alembic anyway: every piece of the migration workflow, explained side by side, plus a clear list of cases where Alembic is still the right call.
Atlas and DBWarden agree on the philosophy: declare the schema you want, let the tool derive the changes. So this comparison is about everything else. Where the schema lives, what gets applied, and who each tool is really for.
Django migrations and DBWarden agree that models should drive schema changes. This post explains how each one does it, where the artifacts differ, and why a FastAPI developer missing makemigrations is exactly who DBWarden was built for.
Every Docker Compose stack I’ve ever operated has suffered from the same quiet flaw: when a container fails, the rest of the fleet is blind to it. The database crashes, and the API keeps hammering it with writes, piling errors into logs. A background worker runs out of memory, and the frontend still shows a green checkmark. Docker restarts the dead container (if you’ve asked it nicely) but no one tells the neighbours what happened, why, or when the danger has passed. ...