yeah, migrations are generated from the Declarative files. For example, the steps are for adding a new column:

1/ Add a new column to the declarative file

2/ Generate a new migration: `supabase db diff -f my_new_migration`

3/ Review/edit the generated migration, check it into git

4/ Apply migration to database

> there is no chance I wouldn't inspect and possibly modify the generated "diff" migration

> Of course, you're generally supposed to do that with these tools

this seems to be the crux of the comments - we'll try to make it much clearer than declarative schemas don't skip any migrations/review process, they just provide another way of generating the migrations (note: you can also generate them directly from the database using the CLI)

> doing this but better

I'm curious what makes it better than the approach in the blog?

If it's this:

> also maintains a schema.sql file that can be loaded as a one-off

That's exactly what the declarative files provide

It is raw sql. The update here is more of a "workflow" change.

In the past we only offered tools to create a sql migration to make a change to your database. Now you can write the state of your database into files, then the migration is generated for you.

This is very similar to something like Rails/Phoenix/whatever, where you write your models and then it generates a change. The difference is that here you write your models in raw SQL, rather than an ORM

> db engineers approve the generated migration script

yeah - this is definitely the intended flow here. We won't be recommending anyone blindly applying generated migrations.

As you mention, it is expected that you generate & review on your local development machine, check into source control, push & merge. We've also been using this internally for ~2 years now and it works great