PgSchemaExporter v2.1.0
PgSchemaExporter is an open-source tool that transforms a PostgreSQL database into a clean, Git-friendly project structure.
Instead of working with one huge schema.sql, every database object is exported into its own SQL file, making schema changes easy to review, compare, and maintain.
What it does
- Export a live PostgreSQL database
- Import an existing pg_dump --schema-only
- Generate a complete project structure
- Create a dependency-aware deploy.sql
- Produce clean Git diffs
- Make database schemas easy to navigate and review
Unlike migration tools (Flyway, Liquibase, Sqitch, Atlas), PgSchemaExporter focuses on keeping the current PostgreSQL schema clean, structured, and Git-friendly.
GitHub: https://github.com/RomanShevel1977/PgSchemaExporter
CLI features
- Include / exclude schemas
- Include / exclude object types
- Include / exclude individual objects
- Schema comparison (diff)
- Cross-platform CLI
- CI/CD friendly
Perfect for
- Version controlling PostgreSQL schemas
- Code reviews
- Database documentation
- Large development teams
- Legacy database refactoring
- AI / LLM context generation
Supported PostgreSQL objects
Core objects
- Schemas
- Tables
- Sequences
- Views
- Materialized Views
Constraints & indexes
- Primary Keys
- Foreign Keys
- Unique Constraints
- Check Constraints
- Exclusion Constraints
- Indexes
Programmability
- Functions
- Procedures
- Triggers
- Event Triggers
- Rules
Security
- Policies (Row Level Security)
Types
- Domains
- Enum Types
- Composite Types
- Range Types
- Base Types
Advanced PostgreSQL features
- Aggregates
- Operators
- Operator Classes
- Operator Families
- Casts
- Extensions
- Collations
- Conversions
Full Text Search
- Configurations
- Dictionaries
- Parsers
- Templates
Foreign Data Wrappers
- Foreign Data Wrappers
- Foreign Servers
- User Mappings
- Foreign Tables
Logical Replication
- Publications
- Subscriptions
I'd really appreciate any feedback, feature requests, or ideas from the PostgreSQL community.
Top comments (2)
Splitting objects into reviewable files is useful, but I’d document one important boundary very explicitly: this is a desired-state snapshot, not a safe migration plan. A dependency-aware
deploy.sqlcan reconstruct an empty database; it cannot infer data backfills, lock-safe constraint validation, enum transitions, column renames, or the expand/contract sequence needed for a live system. CI should test both promises separately: byte-identical export from unchanged catalogs, and successful replay into a clean database followed by a zero diff.The security and portability surfaces are where schema exporters often surprise teams. I’d include owners, grants, default privileges, RLS enabled/forced state, policies,
SECURITY DEFINERflags and functionsearch_path, while making role names/ownership normalization configurable per environment. Conversely, subscriptions, user mappings, foreign-server options, and extension configuration can contain credentials or environment-specific endpoints, so export should redact or fail closed rather than commit secrets. A manifest containing PostgreSQL/tool versions, selected object classes, normalized catalog hashes, excluded objects, and dependency cycles would make a Git diff much easier to trust. One nasty fixture worth adding is a mutually dependent view/function or table cycle, because a topological deploy order needs an explicit strategy for strongly connected components rather than just “dependency-aware.”Thanks for the thoughtful feedback-these are all valid points.
You're absolutely right that PgSchemaExporter is not a migration framework. The generated deploy.sql is intended to recreate a schema from a clean state, not to perform zero-downtime production migrations or replace tools like Flyway, Sqitch, or Atlas.
The goal is deterministic export, a Git-friendly project structure, and reliable schema reconstruction. Production migration workflows are intentionally out of scope.
I also agree about CI. My own validation already includes export >> deploy into a clean database >> export again >> compare for zero diff, and I plan to expand those tests further.
Several of your other suggestions-such as richer manifest metadata, configurable normalization, and better handling of environment-specific objects-are excellent ideas and are now on my roadmap. Thanks for taking the time to write such detailed feedback.