Count the total number of objects in your schema: tables, views, indexes, sequences, procedures, and so on. You'll use this count to find the matching row in the sizing table in the next step.

snapshot and generate-changelog sizing (one schema resident)

diff and diff-changelog sizing (target + reference resident)

Don’t provision machine RAM equal to your -Xmx value. That’s JVM heap only. Size RAM above it: RAM ≈ -Xmx + ~1 GB for metaspace, thread stacks, code cache, and buffers. Add further headroom if your database is co-located on the same machine.

SQL Server diff runs heavier than Oracle at the same object count, because diff-class commands on SQL Server are metadata-latency-bound rather than heap-bound. Actual run time also depends heavily on network latency between Liquibase and the database, storage performance, and current database load.

Because these factors vary by environment, this guidance doesn't publish expected run times. Run a test invocation against a non-production copy of your schema to establish a baseline before scheduling production runs.

Heap usage is driven primarily by object count, dominated by columns. Stored procedures, packages, and package bodies add comparatively little heap (their bodies are streamed to files) but they do add proportionally more processing overhead.

Note: If any object type in your schema exceeds 100k rows, set -Dliquibase.sql.maxResultSetSize=5000000. Without it, snapshot and diff abort quickly instead of streaming through the large result set.

Set -Xmx to the Recommended value from step 2:

JAVA_OPTS="-Xms512m -Xmxyour_xmx_value" liquibase your_command

Be sure to:

• Replace your_xmx_value with the Recommended -Xmx value from step 2, including the unit. For example, 6g, 12g

• Replace your_command with the command you're running. For example, generate-changelog, diff