It often is, but the schema might be written against a language-specific ORM.
That code might in turn have plugins or feature flags that mean you don't know the concrete sql schema until runtime.
Same for seed data and migrations.
So it depends on the use-case how useful this format is for tooling and discovery vs an actual connection to the database.
Sane ORMs will still use sql for migration files
There are a lot of advantages to using a DSL for migration files rather than pure sql. For one, many times you will get both forward and reverse migration ability automatically, to allow rollbacks (with the ability to mark certain migrations as unable to rollback). You also can have the DSL utilize different features depending on which database you are using without having to change your migration. You can also use special syntax to designate relations between tables easily without having to write the boilerplate SQL every time.
If you are using an ORM, using the same language and mental model to describe your database structure as you do to interact with the database makes a lot of sense.
I agree it's much better to, but the biggest ones are probably Django & Rails (?), and they don't.
yeah tbh i was mostly thinking about the newer crop of ts/js ones (kysely/drizzle) vs the earlier mess that TypeORM or others where on its place, so at least its not so bad.