mite

sql schema migrations so easy you already know how to do them

reversible (usually) + incremental changes to the schema of a database.

in their most basic form, these could just be sql files on source control with no automated way to executed them (remember that)

why would I use migrations?

keeping up with the state of database schemas gets complicated really quickly, especially once you have multiple developers + environments.

you need some kind of a tool to manage everything.

[ draw things on whiteboard ]

word of mouth. maybe you email around some schema update sql or put it on source control. or maybe you pass around sql backups (we all hate this)

specific migration frameworks (kind of like mite). a lot of these are configuration heavy, language specific, use a DSL, or a combination of all those...

migrations are just sql. you know sql right?
almost no configuration. just get it pointed at your database
you always have an accurate representation of your schema for the version of code it corresponds to
the CLI is really easy to use
getting a new database environment takes two simple commands: mite init && mite up
language agnostic. use it in any project, with any dev stack, on, pretty much, any operating system
tons of the other solutions are tied to specific frameworks/languages, have clunky GUIs, or an ugly CLI. mite does none of those things...

the original .net/mono implementation had cross platform issues + was a pain to distribute
distribution with npm is super simple
I'm way better at javascript than python
Atwood's Law

ok.