title: Best practices for managing changelogs from different applications
body: <p>We have an API application with 2 REST endpoints, and 2 separate applications writing (independent) tables to the same database to serve as backend for these 2 REST endpoints. You can think of this as an almost-microservices setup with shared DB server.</p>
  <p>We want to use liquibase to manage the database tables from each of these 2 applications, but can't find any best practices guidelines about how to manage the changelog setup.</p>
  <p>Options we are discussing:</p>
  <ol>
  <li>Each application maintains a separate changelog table, with records for the table it maintains.</li>
  </ol>
  <ul>
  <li>Upside - completely independent setup, and sharing DB is co-incidental.</li>
  <li>Downside - The changelog table numbers will increase as we add more tables / applications to feed to the same database. Need to remember which changelog to use for development and look at for debugging.</li>
  </ul>
  <ol start="2">
  <li>Both applications share the same changelog table.</li>
  </ol>
  <ul>
  <li>Upside - Single setup, can use the liquibase default. Easy lookup and maintainance.</li>
  <li>Downside - Possible conflict / wait in case both applications try to deploy at the same time.</li>
  </ul>
  <p>Can someone point me to best practices around this?</p>