EventStoreDB 24.2 released

Today, we are excited to announce that the EventStoreDB 24.2 Release is here. This release is a significant update that introduces a suite of innovative features and enhancements designed to elevate the performance, security, and scalability of your event-native applications. The highlights below represent just the beginning of what EventStoreDB 24.2 offers. Read on to uncover the details of these features and more.

Highlights

• Connector preview with HTTP sink
• X.509 certificates to authenticate clients
• Open Telemetry exporter
• Download logs via EventStoreDB HTTP API
  
• Catch-up subscription mode change without drops
  
• Auto-size of caches and filters disabled in containerized environments
• Deprecation warning

Connector preview with HTTP sink

It is very common for event-sourced systems to adopt the CQRS pattern and project events to other databases for querying. Also, developers often use events stored in EventStoreDB to communicate with other systems using message brokers or event streaming.

Right now, it requires creating a service that hosts a catch-up or persistent subscription. In case of catch-up subscription, this service also needs to maintain the checkpoint. Catch-up subscription services require careful monitoring as they usually run as a single instance, which creates a single point of failure in the system.

EventStoreDB Connector addresses this problem by hosting subscriptions for you. It maintains its own checkpoint, and it moves between cluster nodes if necessary. You can also instruct the connector to run on a specific node kind, like Follower or Read-only Replica.

Video: Demo of Connectors in EventStoreDB 24.2

The first target (sink) that is available in EventStoreDB 24.2 is HTTP. It allows you to create a simple API server, which will be called by the connector. This way, you won't need to maintain any subscriptions, care about subscription drops, checkpointing, and running a single instance that might fail. You can also deploy the API server as a serverless workload available via an HTTP endpoint, so it only uses compute resources when there are events to process.

The feature is now in public preview. We don't recommend using it in production. The management API for connectors is likely to change, but the consumer API is relatively stable. Because it's an early preview, the feature is feature-flagged and needs to be explicitly enabled. For that reason, it's also not available in Event Store Cloud today. We'll work further on making it possible to use connectors in our cloud service soon.

Documentation

X.509 certificates to authenticate clients

We extended the number of ways to authenticate clients with EventStoreDB with X.509 user certificates. It is probably the most secure authentication method available today.

It is only possible to use certificates for client authentication with clusters that run in secure mode. The cluster will use the issuer certificate to validate client certificates.

Currently, the feature is not available in Event Store Cloud, but we plan to support it there in a few months time.

Documentation

Open Telemetry exporter

Since EventStoreDB 23.6, each cluster node exposes an extensive set of metrics that help you observe the cluster health and behavior. Those metrics are exported in Prometheus format, so you can use Prometheus to scrape the metrics endpoint and visualize metrics in Grafana and the like.

The new release adds an Open Telemetry exporter as another way to collect metrics. It uses the Open Telemetry protocol, which is natively supported by a wide range of APM tools and vendors. Using the new exporter, you can send metrics directly to your APM provider without using Prometheus.

The exporter needs to be configured with the Open Telemetry protocol endpoint and (optionally) authorization header. Because of that, it's currently not supported in Event Store Cloud as the managed service doesn't support custom configurations yet. We expect that to be solved in the coming months.

Documentation

Download logs via EventStoreDB HTTP API

EventStoreDB node logs are a great source of diagnostics, but they are only accessible to those who have direct access to the machine where the node runs. One of the obvious use cases is Event Store Cloud, where customers can't get logs from their clusters because they can't remotely log in to those virtual machines. The new set of HTTP API endpoints allows operators to list and download log files without accessing the physical or virtual machine.

There is no user interface support for this feature yet. Check the documentation to see how the API can be used with curl.

Documentation

Catch-up subscription mode change without drops

This update addresses the previous challenge where catchup subscriptions that fell behind would be dropped by the server with the message "Consumer too slow". The client would then need to resubscribe from the last checkpoint to continue receiving events.

As of 24.2.0, catchup subscriptions automatically revert to catch-up mode server-side without user intervention, improving reliability and consistency.

Additionally, subscriptions are now able to re-authorize the user running the subscription in response to user access changes. This means that if you remove a user's access to a stream (for example, through ACLs on the stream), any subscriptions that the user has to that stream will be dropped.

Auto-size of caches and filters disabled in containerized environments

EventStoreDB 24.2.0 is now able to detect when it's running in a containerized environment, and will disable certain auto-configuration options. This helps prevent the node from running out of resources and allows for finer tuning of the EventStoreDB instances.

Deprecation warning

• Make sure you don’t have any applications running that rely on the legacy protocol. Usually, you can see connections from clients that use the legacy protocol on the cluster dashboard in the database UI. Applications that use the current protocol are not shown there. If you have a three node cluster, there must be two connections visible on the cluster dashboard: these are peer cluster nodes.
• If you have any options related to the legacy protocol in the database server node configuration file, the database won’t start.
• It is a good idea to remove these options from the configuration file before upgrading, while you still use a previous version. It allows you to ensure there are no applications that use the legacy protocol. If something stops working, revert the configuration file changes and do not upgrade.
• If you decide not to upgrade, ensure that you configure the OS package manager to hold the current version, otherwise you risk to be upgraded automatically by accident. Refer to your OS documentation to learn how to hold the package version.

How to upgrade?

Please refer to the upgrade guide in our documentation.