Ask HN: Database-first vs. code-first approaches?

I inherited several legacy Python projects written with a database-first approach, i.e. the migrations are written in raw SQL then we update the SQLAlchemy models.

My issues with this approach so far:

- writing SQL migrations is a slow and error-prone process (people here are Python devs (mostly junior btw), not DB/SQL experts)

- reviewing SQL migrations is a slow and error-prone process (for the same reason)

- it's impossible to see the model diffs on Git (each migration is a new SQL file, so we can't compare before/after. I thought about generating schema diffs as text and committing them, allowing the reviewer to see the impacts of every migration, but the diffs are noisy, it's slow to generate, it's 1 more file to commit, and overall it just seems like a hack for patching a bad design choice)

- it's impossible to track the history of the model diffs (for the same reasons)

And I just don't see any benefits for us with the database-first approach.

Does anyone here had a similar experience? Did you move your projects to the other approach?

For context, we have 1 database/schema shared by multiple projects. So I guess we could create a new project handling the SQLAlchemy models/migrations and import it in the other projects.