I tend to prefer Grate for this. And, though migration scripts aren't the same as an active schema, there's other tools to see a current database's schema, and it's easy enough to run on a new/empty db locally if you want to do it offline.
Interesting idea; For schemas migration I like tools like Liquibase/Flyway/Knex, but their main disadvantage is that the more migrations you've had, the harder it's to reason about your current db schema
I want to manage my database items like I manage my code. I get a hierarchical folder structure of items with support for goToDefinition and findReferences, and when I update my code I can run something that generates the diff migration. That way I can see historical context of what has changed and when, rather than looking through migration files grepping for the fields or function names of interest.
The migration log ends up being your changelog, except that it's not a simple diff (create or replace function with the whole definition of the function rather than the diff).
Not much use in the modern world, but SQL Server has this and I've had too many projects to approach doing it for pgsql. In Visual Studio there was a SQL project, and in it you would write your SQL as though you were bringing up the DB from scratch; with directories and all for your convenience.
Internally it would materialize it all into a schema which could not only be used for things like go to def, but also for diffing against another schema - either a previous build, or your live db, and subsequently emitted as a migration. It was magical, but flew under the radar, and these days any individual stuck working with SQL Server deserves many condolences.
I will say though, when you are dealing with many disconnected instances, it can become a nightmare to manage. Such as an "enterprise" or govt app that is deployed to multiple different places at different versions, with different update windows/schedules.
i wish i had a project to test this with over time. i never really loved the idea of writing plain SQL migrations for schema management, purely from an ops perspective. maybe that's partially just because i don't spend enough time reading raw sql queries to put a model together in my head as quickly as i could from something declarative.
What a journey:
AGPL https://github.com/pgschema/pgschema/blob/97f4bf5c00fd10add5...
MIT https://github.com/pgschema/pgschema/blob/53313057201931b2e8...
Whatever the fuck this is, that ain't community that's "I made up a licence how hard can it be": https://github.com/pgschema/pgschema/blob/6f5ce89cc1ac12f4a6...
I tend to prefer Grate for this. And, though migration scripts aren't the same as an active schema, there's other tools to see a current database's schema, and it's easy enough to run on a new/empty db locally if you want to do it offline.
Interesting idea; For schemas migration I like tools like Liquibase/Flyway/Knex, but their main disadvantage is that the more migrations you've had, the harder it's to reason about your current db schema
I've always hoped for something like https://github.com/fordfrog/apgdiff that was comprehensive and maintained.
I want to manage my database items like I manage my code. I get a hierarchical folder structure of items with support for goToDefinition and findReferences, and when I update my code I can run something that generates the diff migration. That way I can see historical context of what has changed and when, rather than looking through migration files grepping for the fields or function names of interest.
The migration log ends up being your changelog, except that it's not a simple diff (create or replace function with the whole definition of the function rather than the diff).
Not much use in the modern world, but SQL Server has this and I've had too many projects to approach doing it for pgsql. In Visual Studio there was a SQL project, and in it you would write your SQL as though you were bringing up the DB from scratch; with directories and all for your convenience.
Internally it would materialize it all into a schema which could not only be used for things like go to def, but also for diffing against another schema - either a previous build, or your live db, and subsequently emitted as a migration. It was magical, but flew under the radar, and these days any individual stuck working with SQL Server deserves many condolences.
I will say though, when you are dealing with many disconnected instances, it can become a nightmare to manage. Such as an "enterprise" or govt app that is deployed to multiple different places at different versions, with different update windows/schedules.
Somewhat related to your ask https://github.com/gajus/pg-dump-parser
We use it internally to create folder-like structure representation of our database schema.
https://github.com/gajus/pg-dump-parser?tab=readme-ov-file#r...
Very handy when reviewing changes in version control, etc.
i wish i had a project to test this with over time. i never really loved the idea of writing plain SQL migrations for schema management, purely from an ops perspective. maybe that's partially just because i don't spend enough time reading raw sql queries to put a model together in my head as quickly as i could from something declarative.