I have been using it for the last five or so years and absolutely love it. I would recommend that you:<p>- Make sure every code feature gets its own Liquibase migration file<p>- Use the XML format—stronger IDE integration, and it&#x27;s been around longer<p>- If possible, use their migrations instead of raw SQL, since you will get the rollback functionality &quot;for free.&quot;<p>- Integrate it with the &quot;deploy&quot; phase of your Maven build, if applicable<p>- Use the &quot;reverse engineer&quot; feature when you get close to deploying it the first time, to ensure that you have a from-scratch workflow that works and produces identical schemas<p>You will get merge conflicts on the file that lists the migrations to apply, but they are obvious and trivial to fix.<p>Pitfalls. The only one I&#x27;ve noticed is that it can be confused about Postgres types, but I have been able to the &quot;rewrite&quot; functionality to &quot;fix them in post.&quot; I tried the YAML format and found that I missed the completion in the IDE that the XML format has, thanks to the schema. Otherwise, it works fine, but I like the validity angle.<p>You can set up some migrations to be run every time. I usually set up the GRANTs that way, so I know the permissions are good right before a code deploy. Also, on those migrations, use an empty &lt;rollback&gt; clause so it doesn&#x27;t prevent you from rolling back (you can do that on any migration to make Liquibase ignore it during a rollback operation, so all my data-manipulation migrations get one too).