Projects was built to work with multiple schemas. You can list then when you init a project and/or add new ones later.

Hi Patrizia and Arvid, I love seeing people with Liquibase backgrounds excited about SQLcl Projects! 😊 Just a few thoughts… Unlike Liquibase, where changesets are manually written or generated as XML, SQLcl Projects begins with making changes directly in the database. Regardless of whether you're using Liquibase, SQLcl Projects, or another tool, changes always need to be applied to a DEV database first to ensure validity and correctness. Some teams follow a structured process—writing Liquibase changelogs/sets to apply changes systematically across environments. While this approach ensures consistency, I often find it introduces too much structure too soon. How often have you created tables or other objects, only to rename or completely rework them multiple times? In general, I recommend focusing on feature development first and committing the final changes to the repo when you're ready. That said, many in the community advocate for a "file-based" approach. We’ve made this easy for soft objects, and in a future post, I’ll demonstrate how SQLcl Projects can handle hard objects and custom DML as well. This compares the current Git branch (e.g., dev) with the default target branch (e.g., prod). If differences exist, SQLcl automatically generates Liquibase-style changesets and organizes them in the dist/releases/next folder. To clarify, many developers expect to compare a feature branch (e.g., 'feature-123') with the branch it was based on (e.g., 'prod')—this aligns with feature branching. On the other hand, comparing 'dev' to 'prod' is more typical for "end-of-release" branching. I’ve blogged about this distinction here: https://danmcghan.hashnode.dev/feature-branches-vs-end-of-release-branches-which-approach-works-best Rollback Support - Not supported—must move forward Liquibase rollback has always been more of a "dev-grade" rollback—it shouldn't be relied on for production deployments. If you take the app/DB offline for an upgrade, you always have the option to restore the database (even via Flashback). This is a true, production-grade way to revert changes. Roll-forward strategies are only necessary for online upgrades where reverting isn’t practical. I’ll blog about this soon too!