Ververica DocsVerverica Docs
Docs Home
Viewing docs for
BYOCNot available for Self-Managed

State Compatibility Check

Applies toBYOC
1 min read
On this page

When you modify a SQL deployment and resume it from existing state, VERA automatically detects changes to SQL statements, runtime parameters, and engine version. Use the state compatibility check to determine whether existing state data can be safely reused before resuming, maximizing state reuse and reducing redeployment effort.

Supported Version

VERA Engine 4.5 or later.

When to Perform a Compatibility Check

Perform a compatibility check when you have modified any of the following and want to resume from the latest or a specific state snapshot:

  • SQL statements in the deployment
  • Runtime parameter configurations
  • Engine version

Perform a State Compatibility Check

  1. In the Console navigation pane, click Deployments.
  2. In the Actions column for the target deployment, click Start.
  3. In the Start Job panel, select Resume Mode.
  4. VERA automatically detects whether changes have been made to the deployment. If changes are detected, click Click to detect next to State Compatibility.
  5. Review the result and follow the recommended action from the Compatibility Results table.
  6. Click Start.

Compatibility Results

ResultWhat It MeansRecommended Action
Fully compatibleThe deployment produces the same results as it would from historical data.Start the deployment.
Partially compatibleOnly specific columns have matching state data. The remaining columns have no state data, causing partial result inconsistency.Start from a different state or without state.
IncompatibleHigh probability of startup failure or unexpected results.Start from a different state or without state.
Compatibility to be determined after a restartThe deployment may fail to start or produce unexpected results.Proceed with caution.

State Data Migration

When state data requires migration after a deployment update, Ververica Cloud uses the Gemini state backend, which performs lazy migration:

  • A state record is migrated only when it is first accessed during job execution.
  • After startup, operators transition quickly from INITIALIZING to RUNNING and begin processing data.
  • Migration completes progressively in the background. When the TPS metric returns to its normal level, all state data has been migrated.

This approach minimizes startup latency — operators do not wait for full migration before processing begins.

Limitations

  • Requires VERA Engine 4.5 or later.
  • Applies to SQL deployments only.
  • State migration uses the Gemini state backend (lazy migration).
Was this helpful?