Skip to main content
Version: 2.15

Ververica Platform 2.15.0

Release Date: 2025-05-15

Changelog​

Ververica Platform 2.15.0 supports the following versions:

  • Apache Flink® 1.20
  • Apache Flink® 1.19
  • Apache Flink® 1.18

Ververica Platform 2.15.0 supports Apache Flink® 1.20, Apache Flink® 1.19, and Apache Flink® 1.18 under SLA.

For Stream Edition the following Apache Flink® Docker images are available. Please check Ververica Platform Docker Images for all available Apache Flink® images and additional tags.

  • 1.18.1-stream5-scala_2.12-java8
  • 1.18.1-stream5-scala_2.12-java11
  • 1.18.1-stream5-scala_2.12-java17
  • 1.19.0-stream3-scala_2.12-java8
  • 1.19.0-stream3-scala_2.12-java11
  • 1.19.0-stream3-scala_2.12-java17
  • 1.20.1-stream1-scala_2.12-java8
  • 1.20.1-stream1-scala_2.12-java11
  • 1.20.1-stream1-scala_2.12-java17

For Spring Edition the following archives are available:

See Flink 1.20 Release Notes and Flink 1.20.1 Release Announcement.

Features​

Built-in Google BigQuery Connector (Read & Write)​

Now in VVP 2.15.0 you can stream data into and out of BigQuery without extra setup. The packaged connector taps BigQuery’s high-speed Storage API for fast, exactly-once reads and writes, so you can plug BigQuery into Flink SQL or DataStream jobs in just a few clicks.

Oracle Support for VVP Persistent Store​

VVP 2.15.0 adds Oracle to our list of remote RDBMSs — joining MariaDB/MySQL, PostgreSQL, and Microsoft SQL Server. Just point the platform to your Oracle instance with a jdbc:oracle:thin URL, enter credentials, and you’re up and running. All enterprise features — versioned deployments, RBAC, auditing, autoscaling policies, and more—continue to work exactly as before.

Kubernetes Events Now Visible in VVP​

VVP 2.15.0 adds a new Kubernetes Events tab to the Events page. With one click you can flip from VVP-generated events to the raw K8s events for the same deployment—ideal for spotting pod restarts, JobUnstable states, or cluster-reachability issues without leaving the VVP UI. Faster root-cause insights mean fewer back-and-forth support tickets and a smoother troubleshooting flow for your team.

Improvements​

Automatic Shutdown for Completed Batch Deployments​

Batch jobs now wrap up exactly the way you expect: when all input is processed and the job reaches FINISHED, VVP immediately marks the deployment finished. This clears up status confusion and makes managing bounded (batch) workloads as straightforward as running a script.

Clearer JDBC-URL Guidance for MySQL / MariaDB Setup​

Using mysql:// in the persistence URL no longer triggers a cryptic driver-class stack trace. VVP 2.15.0 validates the JDBC string at startup and, if MySQL is detected, returns an explicit hint: “Use mariadb:// for MySQL-compatible persistence.” This small tweak saves troubleshooting time during Helm installs and keeps deployments moving.

One-Click Toggle to Disable Checkpointing​

Need to run without checkpoints? VVP 2.15.0 adds a simple toggle in the Advanced tab that turns checkpointing off with a single click. No more hunting for magic values — when the switch is off VVP sends an empty interval, leaving Flink’s checkpointing disabled.

Autopilot API Swagger update​

The /autopilot/.../autopilotpolicy endpoint now provides an accurate Swagger configuration example to eliminate the confusion on how to configure the Autopilot.

Quick View of Running Deployments​

The Deployments page now displays a simple “Running X / Y” indicator, so you instantly know how many of your deployments are active out of the total in the current namespace.

Bug fixes​

CRD Deployments — Resource Fields Now Validate Correctly​

We’ve fixed a schema issue that blocked kubectl apply when resource limits or requests were set in a VvpDeployment manifest.

Clear Error When Resource-Name Prefix Is Too Long​

In VVP 2.15.0, the Kubernetes operator now checks the length of deployment.resource-name-prefix (max 27 characters) before creating a deployment. If the value is too long the UI and operator logs return specific message—“deployment.resource-name-prefix must not exceed 27 characters” — instead of a generic error, so you can correct the setting quickly.

Kubernetes Operator Logs Point to the Real Root-Cause​

When a deployment can’t start, the Kubernetes operator now spells out the underlying problem — namespace typos, HA mis-configs, invalid CR fields — instead of returning a generic ApiException stack trace. Clearer diagnostics make it faster to spot issues and redeploy with confidence.

Checkpoint History Stays Visible After Upgrades​

Upgrading from VVP 2.13 to newer versions no longer hides your checkpoint timeline. Starting with 2.15.0, the Snapshots tab continues to show live checkpoint progress and past savepoints immediately after a Helm upgrade, so jobs keep recovering from the most recent checkpoint without extra steps.

No More Duplicate HA Settings When You Switch Keys​

In earlier versions, changing from the legacy high-availability key to the new high-availability.type — whether in the UI, YAML, REST PATCH, or Kubernetes operator — could leave both keys in the deployment spec and confuse checkpoint recovery. VVP 2.15.0 now replaces the old key with the new one in every update path, so each deployment carries a single, correct HA setting and recovers from the latest checkpoint as expected.

Offline DDL updates failing in 2.14​

The generation of the offline DDL updates was not properly working in 2.14, and it has been fully restored in 2.15.0.

Logs Button Hidden Without Proper Permissions​

The Logs button already checked user permissions, but it still looked active for people who weren’t allowed to view logs. From VVP 2.15.0 onward, the button is hidden/disabled for anyone lacking the necessary access, removing confusion while keeping the same permission rules.

Click a shared job URL while signed out and you’ll land on that exact job right after single-sign-on without needing a second click.

  • Upgraded Spring Boot to 3.4.5 to address CVE-2024-38820, CVE-2024-38827, CVE-2025-22228, CVE-2024-38807, CVE-2023-52428, CVE-2024-7254
  • Upgraded netty to 4.1.119.Final to address CVE-2025-24970, CVE-2025-25193
  • Upgraded jetty to 9.4.57.v20241219 to address CVE-2024-8184, CVE-2024-6763, CVE-2023-36478
  • Upgraded tomcat to 10.1.40 to address CVE-2025-24813
  • Upgraded kafka-clients to 3.8.1 to address CVE-2024-31141, CVE-2024-5612
  • Upgraded commons-configuration2 to 2.11.0 to address CVE-2024-29131, CVE-2024-29133
  • Upgraded commons-io to 2.16.1 to address CVE-2024-47554
  • Upgraded liquibase to 4.31.1 to address CVE-2024-43382, CVE-2025-24789, CVE-2024-24790, CVE-2023-45283, CVE-2024-34156, CVE-2023-45288, CVE-2024-24785, CVE-2023-39326, CVE-2023-45284, CVE-2024-24791, CVE-2024-34155, CVE-2024-24783, CVE-2024-24784, CVE-2023-45289, CVE-2023-45290, CVE-2024-24789, CVE-2024-34158
  • Upgraded logback-core to 1.5.18 to address CVE-2024-12798, CVE-2024-12801
  • Upgraded libexpat to 2.4.7-1ubuntu0.6 to address CVE-2024-50602
  • Upgraded curl to ubuntu/curl 7.81.0-1ubuntu1.20 to address CVE-2024-11053, CVE-2024-9681
  • Upgraded libexpat to 2.4.7-1ubuntu0.6 to address CVE-2024-50602

Upgrade​

As always, we recommend upgrading via Helm using the following commands:

$ helm repo add ververica https://charts.ververica.com
$ helm repo update
$ helm upgrade [RELEASE] ververica/ververica-platform --version 5.11.0 --values custom-values.yaml
On this page