KurrentDB 26.1 is one of our most substantial releases since the rebrand from EventStoreDB. It opens KurrentDB up to a new audience with SQL access, delivers the most concentrated stability work we've ever done on persistent subscriptions, adds a webhook source connector that brings external events straight into your event log, and introduces a brand-new projection engine that sets the stage for what's next.
Here are the highlights. For a full breakdown of what's new in KurrentDB 26.1, check out our documentation .
SQL access for KurrentDB
LICENSE REQUIRED
This is the part of 26.1 that reaches a new audience.
For most of our customers, KurrentDB is the source of truth for the most valuable data their business produces — every order placed, every transaction processed, every state change in their core systems. Until now, getting that data into the modern data stack has meant building and maintaining custom pipelines: subscriptions feeding queues feeding ETL jobs feeding warehouses. It works, but it's plumbing your team needs to own.
26.1 changes that. We've added a query surface to KurrentDB based on Apache Arrow Flight SQL — an open, modern protocol designed specifically for high-performance analytics and it works seamlessly with the standard tools your data team already uses. JDBC, ODBC, and ADBC drivers all connect out of the box, which means KurrentDB now speaks the same language as the platforms where your analytics actually happen.
This brings direct integration with Databricks, Snowflake, and the rest of the modern data stack within reach. Both Databricks and Snowflake have first-class support for federated queries and external data sources via JDBC and Arrow-based connectors, which means events in KurrentDB can be queried, joined with warehouse data, and fed into downstream pipelines without a custom export layer in between. Your event log becomes a queryable source alongside everything else your data team already works with — no Kafka topic to maintain, no nightly export job to debug, no second copy of the data to reconcile. Dbt models, scheduled Snowflake tasks, Databricks notebooks, Power BI dashboards, Tableau workbooks, Jupyter notebooks — all of it can now reach into KurrentDB directly.
The dialect is PostgreSQL-compatible. The default index lives at kdb.records. You can define your own indexes with a JavaScript filter and selector, and they show up as queryable tables alongside the defaults — so you can shape what your analytics tools see without changing how your applications produce events.
This is the first concrete step in bridging the gap between event-based and relational systems. It meets analysts and data engineers in the language they already speak, dramatically shortening the path from "this happened" to "the business knows about it."
For more information, check out our documentation .
Rock-solid persistent subscriptions
Persistent subscriptions are one of the simplest ways to consume events from KurrentDB. The server tracks consumer position, coordinates competing consumers, and manages the ack and nack flow — which means client applications don't have to. You connect, process events, acknowledge them, and let KurrentDB handle the rest. For teams building downstream integrations, fan-out workers, and event-driven services, persistent subscriptions are the fastest path from "we're producing events" to "we're acting on them" — with very little code on the client side.
That simplicity is only valuable if it's rock solid underneath. 26.1 represents our most concentrated stability work on persistent subscriptions to date — methodical, focused engineering work to find and fix the specific issues customers have hit in real-world deployments. This is not an overhaul. The original design is sound. What we've done is harden it.
Stability improvements in 26.1:
- Major performance and stability gains under burst load, with up to 100x throughput improvements in the worst-affected scenarios
- Reliable handling of TCP client reconnects, eliminating a class of stalls that have particularly affected JVM clients
- Smoother recovery during leader changes, so clients no longer hang while the subscription service initializes on a newly elected node
The bottom line: persistent subscriptions in 26.1 are rock solid, and you can rely on them at every level of throughput — from a steady trickle of business events to sustained high-volume workloads. Whatever your scale, persistent subscriptions are now ready for it.
Note: We're also backporting these fixes to the 24.10 LTS stream, so customers who haven't yet moved to 26.x can benefit from the stability work without changing major versions.
For additional details, check out our documentation .
A new webhook source connector
LICENSE REQUIRED
A growing share of the events that matter to your business originate in systems you don't control — SaaS platforms, payment processors, source control providers, collaboration tools, and CDC tools like Debezium and Oracle GoldenGate streaming change events out of your operational databases. They all speak the same language to the outside world: webhooks. Until now, getting those webhook calls into KurrentDB meant standing up middleware to receive HTTP, validate signatures, and append the result. It's the kind of plumbing every team builds, and every team has to maintain.
26.1 introduces a new webhook source connector that eliminates that layer. It accepts webhook calls directly on your KurrentDB endpoint and writes each one as an event — no intermediate service, no extra moving parts.
Highlights of the webhook source connector:
- Direct ingestion of webhook payloads as events, with no middleware in between
- Built-in HMAC signature validation for GitHub, Shopify, Slack, and Stripe out of the box, so requests from those providers are verified before anything is written
- Flexible routing via a small JavaScript function that decides the target stream and event type for each inbound request — you decide how your event streams are organized
- Choice of acknowledgment timing, so callers can either receive an immediate acknowledgment or wait for the event to be durably persisted before responding
The bottom line: Webhooks from your most important integrations now land directly in your event log, with the security and routing controls you need built into the connector itself.
For additional details, check out our documentation .
A new projection engine
Projections are one of KurrentDB's most distinctive capabilities. They let you write JavaScript that runs inside the database, transforming your event log into whatever your application needs: read models for query workloads, derived streams for downstream consumers, denormalized views, integration triggers, business process state, and more. They've been a core part of the platform since EventStoreDB 4.0 and remain one of its most powerful primitives.
The original engine has served customers well for over a decade. But accumulated complexity has made it increasingly difficult to extend, and we want projections to keep evolving. With 26.1, we're shipping a new engine — Projections V2 — that sets the stage for the future of projections in KurrentDB.
Improvements in V2:
- Parallel partition processing, allowing performance gains V1 couldn't deliver
- Atomic checkpointing, removing a category of recovery edge cases that V1 had to defend against
- Reduced storage overhead from eliminating internal "bookkeeping" streams that V1 created behind the scenes — these have historically inflated database size, sometimes significantly
- A simpler internal architecture that's far easier to extend with the new capabilities we have planned
The bottom line: V2 is a substantially better engine under the hood, and your projection code works the same way it always has. The JavaScript API you already know is unchanged.
V2 ships as experimental in 26.1. Most projections will run on V2 without modification, but a few V1 features are not yet supported — trackEmittedStreams, outputState, and biState projections among them — and we'll be filling those gaps in upcoming releases. If your projections rely on those features, stay on V1 for now.
One important note on upgrades. V1 and V2 are not state-compatible. The JavaScript code is identical between them, but the way each engine stores its checkpoints and state is different, so there is no automatic migration path from V1 to V2. Existing projections continue to run on V1, which we are keeping in maintenance mode while we invest the engineering effort behind V2. Newly created projections default to V2.
This was a deliberate decision. Rather than carry V1's complexity forward indefinitely, we chose to draw a clean line and put our energy into the engine that will power the next several years of projection work — and the tooling that goes with it.
For additional details, check out our documentation .
Coming soon: Gaffer
Alongside Projections V2, we've been building Gaffer — a new way to develop, test, debug, and deploy projections that we'll be unveiling in the near future. If you've ever wished projections were easier to work with, keep an eye out for more details coming soon.
Upgrading
26.1 is a non-breaking upgrade. Existing projections keep running, persistent subscription fixes apply automatically, and SQL access can be enabled when you're ready.
- Reach out to your Kurrent contact if you'd like to enable Arrow Flight SQL on your deployment.
- LTS customers on 24.10 will receive the persistent subscription fixes in upcoming patch releases.
If you'd like to talk through what 26.1 means for your specific deployment, get in touch . And as always, the team is active in Discuss and Discord if you want to dig in with us directly.
