redb for business: your team writes business logic, the infrastructure is already built

2026-09-14redb redb.Route redb.Tsak redb.Identity

On September 12 we shipped redb 4.0.0. The ecosystem's four products (a data store, an integration engine, a runtime and an identity server) moved to a shared major version: 76 packages, an internal security audit, and builds on .NET 10, which Microsoft supports until November 2028. The engineering changes are covered in a separate post. This one is for the people deciding what to build a backend on: what the ecosystem replaces, what it costs, which risks it removes, and what to know before you start.

Here's what's in it, briefly:

redb.Core stores typed objects in PostgreSQL, MS SQL Server or SQLite. The data structure is a C# class, the database schema is synchronized from code, and there are no migrations.
redb.Route is an integration engine built on Enterprise Integration Patterns, in the same family as Apache Camel, with 29 transports ranging from Kafka, RabbitMQ and IBM MQ to SOAP, gRPC, AS2 and SFTP.
redb.Tsak is the runtime: modules deploy and swap live, nodes form a cluster, and everything is visible and managed from one dashboard.
redb.Identity is an OpenID Connect and OAuth 2.1 server with HTTP, gRPC and SOAP facades, running as a module of the same runtime.

Your team writes business logic, not infrastructure

In a typical project, before the first line of business logic, the team builds infrastructure: connections to brokers and external systems, retries and duplicate protection, database migrations, zero-downtime deployment, monitoring, authorization. That's months of work in which the business gets no new features, followed by years of maintaining all of it.

In redb that layer is already written, tested and maintained. A developer describes data as a class, a process as a route, and a connection to an external system as a connector address. Everything else goes into what the business actually pays for.

In numbers, counted on real systems:

2.2–4 person-years of infrastructure before the first line of business logic in a TMS built on WSO2 MI and EF Core, and 2.8–4.4 person-years in the payment platform model, plus 0.8–1.1 of a permanent headcount every year to maintain it. At a fully loaded $60–150 per engineering hour, that model comes to roughly $286k–$1.11M up front and $77k–$285k a year. With redb, that layer isn't yours to write or maintain.
Twenty minutes instead of half a day to a day to test a product idea that needs a new field or entity: no migration, no test environment, no rollback script. That's an order of magnitude, and the team gets to compare three to five options instead of shipping the first one that works.
Integration definitions four times shorter: in a migration off an ESB, 861 lines of WSO2 XML became 212 lines of route.

Development moves several times faster not because people type faster, but because they stop writing what has already been written. For the business, that means a shorter path from idea to production and fewer hires for the same roadmap.

What it replaces

Concern	The usual approach	In redb
Data	An ORM, migrations and a separate process to roll them out	The C# class is the schema
Integration	Apache Camel or WSO2 MI on Java, hand-written connectors	redb.Route routes
Runtime and operations	Home-grown glue: zero-downtime deployment, dead-letter queues, dashboards	redb.Tsak
Identity	Keycloak or WSO2 Identity Server on Java, with databases of their own	redb.Identity

The cost of that stack doesn't show up in license fees; it shows up in the sheer volume of someone else's infrastructure. In the breakdown of a real TMS on WSO2 MI and EF Core, the identity server alone brought 227 service tables across four databases, against 53 tables in the system's own business model. Every one of them has to be deployed, backed up and upgraded along with the product. redb.Identity keeps clients, tokens and keys in the same redb store as the rest of your data.

What it costs

Licensing. The open part is Apache 2.0. Pro features (optimized queries, partial change writes, parallel materialization, clustering) are free across the entire 4.x line, commercial use included. No license key, no registration, no per-core or per-node fees. The intent is to keep Pro free beyond 4.x as well. Pro packages are closed source, but the source is available on request to companies that adopt the ecosystem, for security audits, escrow or their own builds.

The real costs are people and hardware. As shown above, your people don't have to write and maintain the infrastructure, and the money side is worked out in the payment platform breakdown: the model is open, the assumptions are stated, and you can plug in your own hourly rate.

People: one language for the whole backend

The data store, integrations, runtime and identity server are written and maintained by one C# team. You don't need separate Java specialists for Camel, Keycloak or WSO2, and you hire from the broad .NET talent pool.

Three rules hold across the ecosystem: a data structure is a class, an entry point is a route, an integration is a connector. A new developer learns one approach instead of five that accumulated over the years, and code review doesn't burn time arguing about the right way to do things.

The integration vocabulary is shared with the industry. Pattern names come from the Enterprise Integration Patterns book that Apache Camel and WSO2 are built on, so an integrator's experience carries over without retraining. Since 4.0, integrations can be described without C# at all, as declarative XML routes in the spirit of WSO2 MI configurations. The markup gives you beans, SQL and the other connectors, reading, querying, saving and deleting objects in the redb store, and transactions. Such a route deploys to Tsak as a package containing a single XML file. Custom code, if you need it, is written in .NET, just as WSO2 MI extensions are written in Java.

Speed of change

A new data field is a new class property. The schema synchronizes at startup, with no migrations and no release windows for them.
Modules swap live, without restarting the node and without a maintenance window; there's a whole section on that below.
An integration can change without recompiling: since 4.0 a module can be a single XML route.
Integrations are tested without brokers. The test kit replaces calls to Kafka, queues and databases with mocks without touching the route itself, so regression testing no longer needs a dedicated environment.

Speed doesn't mean giving up control. Since 4.0, production schema changes can be handed entirely to your DBA: the application stops with a clear message and provides the upgrade script instead of running DDL on its own at startup.

Releases without a maintenance window

Hot deployment and graceful shutdown in redb aren't a feature you switch on before a release; they're the normal lifecycle of every module.

A new module version is checked before the running one is touched. The runtime loads it separately and confirms the package opens and contains a module; if it doesn't, the running version stays as it is. The old version then shuts down gracefully, stops accepting new messages and finishes the ones in progress, after which the new version starts. The brief pause affects only that module's context: the process doesn't restart, and modules in other contexts on the node don't notice the deployment.
Shutdown is graceful by default. A route first stops accepting new messages, then finishes in-flight ones within a configured timeout, and only then closes transports and database connections. Deployment, module removal and shutting down a whole node all work this way: a node first gives up cluster leadership, then stops its contexts, and one slow context can't cut short the shutdown of the others.
Nodes are serviced without downtime. A cordoned node takes no new work and hands its cluster routes to its peers, after which it can be upgraded or rebooted. A readiness check tells Kubernetes when a node can't do its work.
In money terms: in the payment platform model, preparing and running release windows costs about 450 hours a year. Here there's no window to run, and deployment stops being a late-night event with people on call.

All of this is about deploying your modules. Moving the platform itself to a new major version, such as 4.0, is planned separately: the nodes of one cluster group are upgraded together, and on a large database the schema upgrade is best done ahead of time in a quiet window.

Operations

No new database required. redb installs straight into an existing production database, PostgreSQL or MS SQL Server: its tables and functions sit next to yours and leave other objects alone. Backups, replication and database monitoring stay as they are, and if that's how your organization works, the DBA runs the install from a ready-made script.
A cluster without double processing. Since 4.0, uniqueness in the cluster is enforced by the database itself: one module is never assigned to two nodes, and two nodes starting on an empty database don't create two clusters.
Multiple clusters are built into the structure. The topology is a tree of cluster, group and node, and one database holds several clusters with their own groups and nodes. Inter-cluster communication, including across regions, is on the roadmap; until it lands, clusters in different regions are connected with redb.Route routes over a broker or HTTP.
One dashboard for every node: routes, errors, the dead-letter queue with replay, the audit log, logs. Prometheus scrapes the metrics, traces go to OpenTelemetry, and nodes deploy to Kubernetes.
A traffic spike doesn't take down its neighbors. Since 4.0 every entry point can have its own limit: excess requests are rejected before processing starts, while neighboring routes on the same port keep working. The dashboard shows which routes hit their limit, which tells you where capacity is short before errors appear.
High-frequency streams in the same database. Vehicle coordinates, sensor readings and other streams are ingested by redb.Route connectors: Kafka, MQTT, RabbitMQ and the rest. Raw points aren't written as redb objects but into ordinary time-series tables (partitioned ones, for example) in the same database, as bulk inserts batched by a route aggregator. The stream needs no separate database, and a foreign key to a redb object (a vehicle, a trip, a sensor) works as in any other table. Objects hold the entities and totals, time-series tables hold the raw stream, just as in the TMS architecture.
One build, two topologies. The same modules deploy as a monolith or as a cluster of microservices; the Tsak post covers this in detail.

Security and audit

Module code is signed. The runtime can be configured to refuse unsigned modules, and the signature is applied with your key in your build pipeline. The ecosystem's release archives are signed with cosign.
Third-party modules run separately. A module runs with the rights of the worker process, and a signature proves who built it but doesn't limit what it does. So a module from a vendor whose code you haven't reviewed is deployed in its own worker container: the OS and the container provide the isolation, and it's managed from the same dashboard as everything else.
The identity server is checked against the official OpenID Foundation conformance suite. The Config OP and Basic OP (35 modules) profiles pass with zero failures. The suite is open source and runs in Docker, and the results and run steps are published in the repository, so anyone can reproduce the check; here's how the run went. The protocol work for formal certification is done, while the OpenID Certified mark itself is granted by the Foundation through a separate paid application. Out of the box: multi-factor authentication, federation with external providers and LDAP, SCIM, DPoP.
Before 4.0, the Identity facades and the Tsak dashboard went through an internal security audit, and everything it found is fixed in this release. Since 4.0, access tokens carry an RFC 9068 audience, so a token issued for an external API doesn't open the identity server's management API.
A change journal for auditors. Since 4.0, write interceptors give the application "who changed what, and when" without touching business code, and in partial change-write mode (Pro) the per-field before and after values as well. Runtime administrator actions go to a separate journal.

Independence from the vendor

Everything runs inside your perimeter. No SaaS, no license server, and nothing goes back to the vendor: neither license checks nor usage data. The routes' own telemetry doesn't send itself anywhere: your Prometheus scrapes metrics from the node, and OpenTelemetry trace export is off by default and gets turned on with the address of your collector or Jaeger. Packages and images mirror into your internal feed and registry, after which no access to outside services is needed.
Your data stays yours. It lives in your PostgreSQL, MS SQL Server or SQLite, the storage layout is open and documented, and the database is readable with plain SQL. Built-in export and import cover the whole database, including between different database engines.
Data residency is decided by where you deploy. The system doesn't depend on an outside licensor or an external service, so regulated and air-gapped environments run it the same way as any other.

Who's behind it

redb is an ecosystem of four products on a single release line. The project already has an outside contributor, and we welcome more: contributions go through GitHub, with the rules in CONTRIBUTING.md. Its direction is shaped by feedback: GitHub discussions, external security reports, comments on articles.

What matters for a business isn't the size of the team; it's what stays in your hands whatever happens: open source under Apache 2.0, Pro source on request, data in your own database, and releases with signed artifacts and public changelogs for every product. Fixes are pinned by integration tests on three databases. Libraries target .NET 8, 9 and 10, and .NET 10 is supported by Microsoft until November 2028.

Deployment (including to the cloud), support, implementation help and SLAs are available by arrangement. So is a provider for another database, such as Oracle or MySQL; PostgreSQL, MS SQL Server and SQLite are supported out of the box. You can get in touch through redbase.app/about.

What to know before you start

redb is the platform your product is built on. Accounting, pricing, logistics and the rest of your domain logic are written by your team or by a third-party vendor by arrangement, while the infrastructure underneath is already in place.
It runs where you deploy it. redb runs on your servers or in your cloud rather than as a subscription service, and deployment and support can be handed to third-party vendors by arrangement.

Getting started

You don't have to adopt the whole ecosystem at once, and a phased rollout breaks nothing: redb sits next to what already runs, in the same database and alongside your existing systems. A pilot with a single module is a good way in: pick an integration or service with a clear boundary, move it over and compare the upkeep under real load. That's exactly what the ESB migration story did, counting the move of one module line by line. From there, modules move over one at a time, at whatever pace suits the business.

For a first look, the redb-tsak-stack image, with the runtime and dashboard in one container, is all you need. Packages are on NuGet and the source is on GitHub. To talk about a pilot, implementation or support, reach out through redbase.app/about.

If this was useful — a ⭐ on GitHub helps others find it.

More of my writing: redbase.app/articles, and on dev.to.