DEV Community: rinat kozin

Enterprise Integration Patterns in .NET, the deep-dive series — Part 1: the four in-memory channels (and the Exchange they carry)

rinat kozin — Mon, 01 Jun 2026 21:51:33 +0000

The earlier posts were the tour: what redb.Route is, an Apache Camel-style ESB for .NET — a fluent C# integration DSL with 22 connector projects (~30 URI schemes once you count the https/wss/es variants), ~30 Enterprise Integration Patterns implemented natively across 41 processors, 8 in-process components, a compiled expression engine, and a pluggable marshal/unmarshal layer. Enough touring.

This starts a deep-dive series — one piece at a time, the actual DSL, the actual semantics, the gotchas that bite you the first time. Not a feature list. A working manual. The series runs on four parallel tracks; you can follow whichever maps to the problem in front of you.

Track A — the in-process foundation (8 components)

The wires and the message model everything else stands on. Small surface, deep behavior.

The four channels + the Exchange — direct, direct-vm, seda, vm, and the object they carry. (this post — the foundation)
Scheduling & test components — timer, plus quartz/cron built on the same idea, and the log / mock / validator components you'll actually lean on in tests.

Track B — the Enterprise Integration Patterns (~30, across 41 processors)

Grouped the way Hohpe & Woolf's Enterprise Integration Patterns groups them, one article per cluster, each dissected against the shipped processor. (The codebase has 41 processors total; a handful — To, Log, Delegate, RoutePolicy — are plumbing rather than named patterns, so the honest count of distinct EIP is around thirty plus the 6 load-balancer strategies.)

Message Routing — Choice (Content-Based Router), Filter, Splitter (+ streaming splitter), Aggregator, Resequencer, Multicast, RecipientList, ScatterGather, DynamicRouter, LoadBalance (Round-Robin / Random / Weighted / Sticky / Failover).
Message Transformation — Marshal/Unmarshal and the data-format registry, ConvertBody, Enrich/PollEnrich (Content Enricher), ClaimCheck, StreamCaching, Normalize, and Transform/SetBody/SetHeader over the expression engine.
Messaging Endpoints — IdempotentConsumer, WireTap, competing consumers (seda/vm concurrentConsumers), Pipeline, request/reply (InOut), Bean<T>.
System Management & Reliability — OnException / TryCatch / DeadLetterChannel, CircuitBreaker, Throttle / KeyedThrottle, Delay / Debounce / Sampling, Timeout, Loop, Saga (+ compensation), RoutePolicy, Transaction/Transacted, and Validate (JSON Schema / XSD).

Track C — the expression & predicate engine (its own article, and it earns it)

The one piece every other track quietly depends on. I almost wrote it off as string interpolation in the roadmap — then I read the source. It's a genuine compiled little language: Tokenizer → Parser → an AST (BinaryOperationNode, UnaryOperationNode, FunctionCallNode, TernaryNode, PostfixOperationNode, property/index access), lowered to System.Linq.Expressions and .Compile()d to real IL — not tree-walked at runtime. There's a dedicated article because there's a dedicated language:

The ${...} Simple-style template isn't formatting — it's the entry point to the whole grammar: arithmetic (+ - * /), comparison, AND/OR/XOR/NOT, the ternary ?:, even postfix ++/--.
~22 built-in functions, mined from the AST's FunctionCallNode: string (concat, upper, lower, trim, substring, replace, length, contains, startswith, endswith), numeric (abs, round, min, max), aggregates (sum, avg, count), date math (now, dateformat, dateadd), and the two that bridge into the structured world: jpath(...) and xpath(...).
JSONPath and XPath as first-class expression types — typed (TypedJsonPathExpression, TypedXPathExpression) and precompiled (CompiledJPathExpression, CompiledXPathExpression) when the path itself is static.
The predicate builders — the fluent half, for .Filter/.Choice/.Validate: isEqualTo, isNotEqualTo, isGreaterThan/isLessThan (…OrEqualTo), isBetween, contains, startsWith, endsWith, regex, In(...), isNull/isNotNull, composed with and/or/not. Seventeen of them, each a real IPredicate, not a closure.
Four separate ConcurrentDictionary compile-and-cache pools (template / property-resolver / logical / value) so every one of the above compiles once per distinct expression string and runs as a cached delegate forever after.

That's why it's its own installment, and honestly why it might be two: the template grammar and the predicate DSL are different front-ends onto the same compiler.

Track D — the 22 connectors, one article each

One focused article per connector, every example lifted from real production routes, not toy snippets:

Brokers & messaging — kafka, rabbitmq, amqp, asb (Azure Service Bus), wmq (IBM MQ), mqtt.
RPC & web — http/https, grpc, signalr, ws/wss, tcp.
Data & storage — sql, redis, elasticsearch, s3.
Files & transfer — file, ftp, sftp.
Enterprise & misc — smtp/pop3/imap (mail), ldap, fcm/fstore/fbstorage (Firebase), qtimer/cron (Quartz).

We start with Track A on purpose. Every pattern in Track B, every expression in Track C, and every connector in Track D is built on two things: a channel that carries a message from one route segment to the next, and the Exchange that is the message. Get these two right and the rest of the series is just composition. Get them wrong and you'll spend an afternoon wondering why your transaction silently didn't roll back.

A pipeline in redb.Route is From → [processors] → To. Let's look at what actually flows through it.

The Exchange — the heart, and it isn't simple

Everything that moves through a route is an IExchange. Not a byte[], not your DTO — an Exchange, a small object with more going on inside it than the name suggests. Here's the shape that matters:

public interface IExchange : IAsyncDisposable
{
    IMessage  In  { get; set; }     // the primary message — always present
    IMessage? Out { get; set; }     // the reply — lazy, null until you need it
    ExchangePattern Pattern { get; set; }   // InOnly (default), InOut, or OutOnly

    IDictionary<string, object?> Properties { get; }   // route-level metadata
    Exception? Exception { get; set; }                 // error state, in-band
    bool ExceptionHandled { get; set; }
    string ExchangeId { get; }                         // identity, stable across clones

    IExchange Clone();                                 // deep-ish copy + NEW DI scope
    IServiceProvider? ServiceProvider { get; }         // per-exchange DI scope
}

And the message it carries:

public interface IMessage
{
    object? Body { get; set; }                        // your payload — any object, or null
    string? ContentType { get; set; }
    IDictionary<string, object?> Headers { get; }     // metadata that DOES travel to brokers
    T? GetHeader<T>(string key);
    IMessage Clone();
}

Five things about this object decide how every channel and every pattern behaves. None of them are obvious from the type signature.

1. `In` vs `Out`, and the `Pattern`

In is the message coming through. Out is the reply, and it's lazy — for the default InOnly pattern it stays null and is never allocated. It only appears when a processor explicitly sets it (request/reply, or .Respond()).

There are three patterns, not two — this is the Apache Camel 2.x model, ported wholesale:

public enum ExchangePattern
{
    InOnly  = 0,   // fire-and-forget. Producer result is written to In; Out stays null. (default)
    InOut   = 1,   // request/reply. Original preserved in In, response written to Out.
    OutOnly = 2,   // explicit response via .Respond(); the RPC reply is taken from Out.
}

Here's the part the type signature hides, and the one place people get it wrong: HasOut does not tell you where the answer is. Even on an InOut exchange, a processor isn't obligated to populate Out — if it just mutates In.Body, the result lives in In. So the framework never trusts HasOut to find a reply. It reads Out ?? In, every time:

// ProducerTemplate.RequestBody — the canonical reply-extraction rule
exchange.Pattern = ExchangePattern.InOut;
await producer.Process(exchange);
return exchange.Out?.Body ?? exchange.In.Body;   // Out if present, otherwise In

This is verbatim how Camel's ProducerTemplate extracts a result (getResultMessage: "has Out → use Out, else In"). Copy that rule into your own code — exchange.Out ?? exchange.In — and you'll never chase a reply that quietly stayed in In. HasOut is a fact about allocation, not about where the data is; don't use it to route on the answer.

One honesty note for the JVM crowd: the live Out message and the OutOnly pattern are Camel 2.x semantics. Camel 3+ deprecated getOut()/setOut() and collapsed the pattern set toward InOnly/InOut, precisely because a separate Out message copied headers and bred subtle bugs. redb.Route keeps the fuller 2.x model on purpose — but if you're coming from modern Camel, that's the difference you'll notice first.

2. `Properties` vs `Headers` — the distinction that leaks bugs

Both are IDictionary<string, object?>. They are not interchangeable:

In.Headers travel with the message to the broker. Put a correlationId here and Kafka/RabbitMQ carry it downstream.
exchange.Properties are route-level metadata — RouteId, transaction markers, your own scratch state. They do not leave the process (the interface XML doc says exactly that: "Does NOT travel to brokers — use In.Headers for that"). Stash a DbContext handle or a retry counter here.

Put a value in the wrong dictionary and it either fails to reach the consumer (you used Properties) or leaks internal state onto the wire (you used Headers). The compiler won't catch it; both are just string-keyed dictionaries. Knowing which is which is half of using the framework correctly.

Read either with the typed accessors instead of casting by hand:

var attempt = exchange.GetProperty<int>("retryCount");     // route-level, stays in-process
var corr    = exchange.In.GetHeader<string>("correlationId"); // travels to the broker

The well-known keys the framework itself writes

This is the part that makes the section concrete, and it's the answer to "what's actually in Properties?" The pipeline and the processors populate a set of reserved keys as your exchange flows. There is no single ExchangeProperties constants file — they live next to the processor that owns each one — but here is the real registry, mined from source.

exchange.Properties — route-level, never leave the process:

Key	Constant in code	Written by	Meaning
`TRANSACT_ACTION`	`TransactedProcessor.TransactActionPropertyKey`	`.Transacted()`	the transacted-action stack for synchronization
`TRANSACTION_SCOPE`	`BeginTransactionProcessor.ScopePropertyKey` (internal)	`.Transaction()`	the live `TransactionScope` for the block
`CamelDuplicateMessage`	`IdempotentConsumerProcessor.DuplicatePropertyKey`	Idempotent Consumer	`true` when the message was seen before
`ClaimCheck.Stack`	`ClaimCheckHeaders.StackPropertyKey` (internal)	Claim Check	the stack of stored payload keys
`ValidationErrors` / `ValidationResult`	`ValidateProcessor.*Property`	`.Validate()`	validation outcome for the current exchange
`CamelSplitSize`	— (streaming splitter)	streaming Splitter	running count of split parts
`__redb_scope:*`	— (prefix)	DI plumbing	named child DI scopes, freed by `ReleaseScopes()`

Plus RouteId is promoted to a first-class property on the exchange (exchange.RouteId), not just a dictionary entry — that's what the logger prints as [rId:…].

In.Headers — travel with the message:

The Camel-compatible message headers come from the same world Camel users expect. The Splitter, for example, stamps every part:

// SplitterProcessor — each split message carries its coordinates
splitMessage.Headers["CamelSplitIndex"]    = index;          // 0-based position
splitMessage.Headers["CamelSplitSize"]     = total;          // batch size
splitMessage.Headers["CamelSplitComplete"] = index == total - 1; // last one?

and every transport contributes its own namespaced header constants — KafkaHeaders (redbKafka.Topic, redbKafka.Partition, redbKafka.Offset, …), SqlHeaders (redbSql.rowCount, redbSql.generatedKeys, …), SignalRHeaders (redbSignalR.ConnectionId, …), TcpHeaders, WsHeaders, ElasticsearchHeaders. Each is a static class of public const string so you bind against KafkaHeaders.Offset, not a stringly-typed "redbKafka.Offset" you might misspell. The rule of thumb: anything prefixed Camel* or redb<Transport>.* is a header (on the wire); anything in Properties is yours and the process's alone.

3. The exception travels in-band

When a processor throws, the exception doesn't just unwind the stack — it's captured onto exchange.Exception, with an ExceptionHandled flag beside it. That's what makes a dead-letter route able to branch on why something failed (when e.Exception is TimeoutException → …) instead of just that it failed. The error becomes data you can route on. We lean on this hard in the error-handling installment.

4. `ExchangeId` is stable across clones

Each exchange gets a Guid-based ExchangeId at creation. The non-obvious part: Clone() preserves it. A split into 500 parts, or a seda hop that clones the exchange, keeps the same id — so your logs and traces stitch the whole flow back to one origin. Identity survives copying; that's deliberate.

5. The DI scope — and four ways to copy an exchange

This is the part that's genuinely not simple, and it's the reason the channels behave the way they do.

An Exchange can own a DI scope — a per-message IServiceScope. Processors resolve scoped services (DbContext, IRedbService, …) from exchange.ServiceProvider, and they get the same instances for the lifetime of that exchange. A TransactionScope lives in exactly that scope. So the question "are these two exchanges in the same transaction?" reduces to "do they share a DI scope?"

There are four ways an exchange gets copied, and they differ only in what they do with that scope:

Method	Body/Headers	DI scope	Owns scope?	Use
`Clone()`	copied	new scope	yes	hand-off to another thread (`seda`, `vm`)
`CloneLinked()`	copied	shares parent's	no	parallel fan-out inside the parent's transaction
`CreateChild(msg)`	new message	new scope	yes	a derived exchange, independent lifetime
`CreateLinkedChild(msg)`	new message	shares parent's	no	sequential children reusing the same connection

// from Exchange.Clone() — the scope-creating branch
if (_scopeFactory != null)
{
    clone._scopeFactory = _scopeFactory;
    clone._scope = _scopeFactory.CreateScope();   // <-- a brand-new scope
}

// from Exchange.CloneLinked() — the scope-sharing branch
_ownsScope = false,
_scope = _scope,            // <-- the SAME scope, and we won't dispose it
_scopeFactory = _scopeFactory

Hold onto that table. The entire transaction story of seda vs direct, and of Multicast vs a broker hop, is just which row got used. Clone() (new scope) means a new transaction; CloneLinked() (shared scope) means the same one.

There's also ReleaseScopes() — it disposes the DI scopes without touching the Body, so an aggregator can free database connections early while still holding the message data it's accumulating. And DisposeAsync() cleans up both the body (streams, stream caches) and the scopes. The object is IAsyncDisposable for a reason.

The gotcha: `Clone()` does NOT deep-copy the Body

Read Message.Clone() literally:

public IMessage Clone()
{
    var clone = new Message(Body) { ContentType = ContentType };  // Body reference copied
    foreach (var kvp in _headers)
        clone._headers[kvp.Key] = kvp.Value;
    return clone;
}

Headers get a fresh dictionary. Body is copied by reference. After a seda hop the producer's exchange and the worker's clone have independent headers, properties, and DI scopes — but they point at the same body object. If that body is a mutable List<T> or a POCO and both sides write to it, you have a data race the cloning looks like it prevented. The XML doc says "deep copy"; the honest truth is "deep copy of everything except the payload." Treat the body as immutable once it's in flight, or clone it yourself.

Two APIs on purpose

One last thing you'll notice in IntelliSense: every member has a C# idiomatic form (In, Body, GetHeader<T>) and a Java-style alias (getIn(), setBody(), getHeader<T>()). They're default interface methods over the same state, kept so the model reads the same as Apache Camel for anyone coming from the JVM. Use whichever; they're the same object.

Now — the wires that carry this thing.

The four channels — two axes

direct, direct-vm, seda, vm are how route segments talk to each other inside a process. Choosing between them is the single most common thing newcomers get wrong, and now you have the vocabulary for why: it comes down to threading and scope. They split on two axes — sync vs async, and one context vs across contexts:

Scheme	Sync/Async	Scope	Clones the exchange?	Same transaction?
`direct://`	synchronous	one context	no	yes — same thread, same scope
`direct-vm://`	synchronous	across contexts	no	yes
`seda://`	asynchronous	one context	yes (`Clone()`)	no — new scope
`vm://`	asynchronous	across contexts	yes	no

direct is the contrast. seda is where the real work — and the real footguns — live, so that's where we'll spend the page.

`direct://` — a method call wearing a URI

direct is not a queue. No thread, no buffer. A producer sending to a direct endpoint invokes the consumer's processor synchronously, on the same thread:

// the whole of DirectProducer.Process
var processor = _endpoint.ConsumerProcessor
    ?? throw new InvalidOperationException("No consumer registered for direct endpoint ...");
await processor.Process(exchange, ct);

The exchange is not cloned. Same object, same thread, same DI scope — straight to the consumer. Three consequences follow:

Exceptions propagate back to the caller. A throw in the direct consumer surfaces in the producer's route, where OnException/DoTry can catch it. (Remember §3 — it also lands on exchange.Exception.)
It's the same transaction. Same scope from the table above, so a direct hop inside a .Transaction() block commits and rolls back with everything around it.
The consumer must be started first, or the send throws. direct decouples your route definitions into named sub-routes — not your threads.

That's the entire personality of direct: a zero-cost, in-transaction call you can give a URI and reuse. It has no parameters because it has no machinery. Use it to break a big route into readable, reusable pieces.

`seda://` — the async queue, in detail

seda (Staged Event-Driven Architecture) is the opposite of direct in every cell of the table. It's a real in-memory queue built on System.Threading.Channels. The producer enqueues and returns immediately; one or more background workers drain the queue on their own threads.

// SedaProducer.Process — the whole thing
var copy = exchange.Clone();                       // §5: new scope. the trap lives here.
await _endpoint.Queue.Writer.WriteAsync(copy, ct);

Two facts are baked into those two lines, and everything else about seda follows from them: it clones (so the worker and producer never share scope — that Clone() is row 1 of the table, a new scope), and it returns before the work is done (so the producer's thread, and its transaction, move on).

The parameters

seda takes three, all on the URI: seda://name?concurrentConsumers=4&size=1000&timeout=30000.

Parameter	Default	What it does	When to change it
`concurrentConsumers`	`1`	Number of worker loops draining the queue in parallel	Raise when the downstream is slower than the inflow and order doesn't matter
`size`	`0` (unbounded)	Max queued exchanges. `0` = grow without limit; `>0` = bounded with `Wait` backpressure	Set a bound whenever the producer can outpace the consumer (almost always, in production)
`timeout`	`30000`	Declared as the enqueue wait for a bounded queue — see the honesty note below	—

`concurrentConsumers` — throughput, at the cost of order

One worker is the default and keeps strict FIFO. Raising it spins up N independent loops:

// SedaConsumer.RunAsync
_workers = new Task[_options.ConcurrentConsumers];
for (var i = 0; i < _options.ConcurrentConsumers; i++)
    _workers[i] = WorkerLoop(pollCt, processingCt);

// each worker
await foreach (var exchange in _endpoint.Queue.Reader.ReadAllAsync(pollCt))
{
    await ProcessWithTracking(exchange, processingCt);
    Interlocked.Increment(ref _processedCount);
}

Two consequences worth stating plainly:

You trade ordering for throughput. With concurrentConsumers=1 the channel runs in SingleReader mode (a real optimization in System.Threading.Channels) and messages come out in order. With N>1, N workers pull concurrently and strict FIFO is gone — message 2 can finish before message 1. Only raise it when out-of-order processing is acceptable.
It's per-endpoint backpressure relief: a slow downstream stops blocking the upstream producer, because the producer only ever writes to the queue and leaves.

`size` — bounded vs unbounded, and why you almost always want bounded

This is the parameter people skip and regret. The endpoint picks the channel implementation off size:

Queue = options.Size > 0
    ? Channel.CreateBounded<IExchange>(new BoundedChannelOptions(options.Size)
      {
          FullMode = BoundedChannelFullMode.Wait,    // producer awaits a free slot
          SingleReader = options.ConcurrentConsumers == 1,
          SingleWriter = false
      })
    : Channel.CreateUnbounded<IExchange>(/* ... */); // grows until you run out of memory

size=0 (default, unbounded): the queue grows as fast as producers write. If the consumer can't keep up, that's an unbounded memory leak with extra steps. Fine for bursty, bounded-volume work; dangerous for a firehose.
size>0 (bounded): FullMode = Wait means a full queue makes the producer await a free slot — backpressure that pushes the slowdown upstream instead of into your heap. This is what you want in production.

// bounded SEDA: 4 workers, at most 1000 queued, producer waits when full
From("seda://enrich?concurrentConsumers=4&size=1000")
    .Process(async (ex, ct) => await Enrich(ex, ct))
    .To("rabbitmq://enriched");

`timeout` — an honesty note

The options object documents timeout (default 30000 ms) as the enqueue wait for a bounded queue. Being straight with you: in the current code the producer enqueues with WriteAsync(copy, ct) and does not apply that timeout — a full bounded queue makes the producer wait on the channel until a slot frees or the CancellationToken fires, not until 30 seconds elapse. So today, plan around size and the cancellation token; treat timeout as declared-but-not-yet-wired and don't build a deadline assumption on it. (Flagging it here because guessing at framework behavior from a doc-comment is exactly how you ship a bug.)

Graceful shutdown — `seda` drains, it doesn't drop

When a route stops, seda doesn't throw away what's already queued:

// SedaConsumer.OnStopAccepting
_endpoint.Queue.Writer.TryComplete();   // stop accepting new; let readers finish

Completing the writer makes the workers' ReadAllAsync loop finish the remaining items and then exit cleanly (SedaConsumer is a DrainableConsumer). On a graceful stop, in-flight queued exchanges are processed, not lost.

The durability caveat

seda is in-memory and non-durable. A graceful stop drains; a crash or a hard kill does not — whatever was sitting in the channel is gone. seda is at-most-once across a process restart. When you need the queue to survive a restart, that's a broker (rabbitmq, kafka), not seda. seda is for decoupling within a process, not for durability.

The transaction trap, stated once and for all

Now §5 pays off. Because seda calls Clone() — row 1, a new DI scope on a different thread — anything past a seda:// hop is not in the caller's transaction.

From("kafka://orders")
    .Transaction()
        .To(Sql.Execute("INSERT …").Transacted())
        .To("seda://post-process")     // runs in a NEW scope, on another thread,
    .EndTransaction();                 //    OUTSIDE this transaction

If post-process throws, the INSERT above has already committed — the seda hop left the transaction the moment it cloned. This is the one mistake everyone makes exactly once. The fix is the table: if the hop must share the transaction, use direct (no clone, same scope); if you genuinely want to hand the work off and move on, seda is correct and you accept the new boundary. The DSL is the same; the scope is everything.

Mental model: direct = function call, seda = mailbox. One preserves your thread and your transaction; the other trades both for throughput and isolation.

`direct-vm://` and `vm://` — the same two, across module boundaries

In a multi-module host (this is how redb.Tsak runs several modules in one process) each module is its own RouteContext. Plain direct and seda are scoped to a single context — a producer in module A can't see a direct consumer in module B. The -vm variants lift exactly that wall by sharing the processor registry, and for vm the channel, through a SharedVmRegistry DI singleton:

direct-vm:// — synchronous, cross-context, no clone. A consumer in the billing module exposes direct-vm://charge; a producer in orders calls it like a local in-transaction method.
vm:// — asynchronous, cross-context, cloned-and-queued. The cross-module twin of seda, with the same concurrentConsumers and size parameters (and the same Clone(), so the same transaction boundary and the same shared-Body caveat).

The rule transfers cleanly: direct-vm for a synchronous cross-module call that shares the caller's transaction; vm for hand-it-off-and-move-on across modules. Same semantics as their in-context twins — just a wider blast radius.

Picking a channel

The whole decision in one table:

You want…	Channel
A reusable sub-route, same thread, inside my transaction	`direct://`
The above, but the consumer lives in another module	`direct-vm://`
To hand work off to a background worker and not wait	`seda://`
The above, across module boundaries	`vm://`
Survival across a process restart	not a channel — a broker (`rabbitmq`, `kafka`)

And the two facts that drive every row: does it clone (new scope = new transaction), and does it return before the work is done. Everything else is detail.

What's next

That's the foundation. You now know what flows through a route (Exchange — In/Out, Properties vs Headers, in-band exceptions, and the four scope-aware clone variants) and the four wires that carry it (direct/direct-vm sync-and-in-transaction, seda/vm async-and-isolated), down to the parameter that decides whether your queue applies backpressure or eats your heap.

Next in the series — Part 2: Splitter + Aggregator. We fan one message into many, process them with bounded parallelism, and re-assemble — and the Clone() vs CloneLinked() distinction from §5 turns out to be the whole story of whether the split shares the parent's transaction. Plus the aggregation-strategy contract where the first call hands you a null accumulator. Subscribe to the series if you want it when it lands.

If anything here fought you — especially the seda transaction boundary or the shared-Body clone — say so in the comments. That feedback is exactly what an early OSS release is for.

Links


redb.Route	github.com/redbase-app/redb-route
redb.Tsak (runtime / multi-module host)	github.com/redbase-app/redb-tsak
redb.Core (storage)	github.com/redbase-app/redb
Discussions	github.com/redbase-app/redb-route/discussions

All Apache 2.0. Questions in the comments are welcome — especially "does channel X do Y?", because that's how the docs get written.

RedBase / redb.Route / redb.Tsak 3.0.0 shipped

rinat kozin — Sun, 31 May 2026 14:26:56 +0000

redb hit 20k NuGet downloads

Three packages, one version bump.

RedBase 3.0.0 — Free tier now generates the same pivot CTE as Pro. array_agg FILTER on PostgreSQL, MAX CASE WHEN on MSSql. Same base-field pushdown, same index path. MSSql Free went from 0 to 145/145 parity tests. Auto-deployed SQL bundle on version mismatch — no DBA in the loop.

redb.Route 3.0.0 — the entire v1/v2 dual compiler stack is gone. One canonical RouteDefinition, AST built from IProcessorDefinition nodes. Dynamic endpoints (ToD, dynamic WireTap/Enrich), string-template DSL (${header.x}, ${body}), full OnException fluent parity with Apache Camel.

redb.Tsak 3.0.0 — runtime container for redb.Route pipelines. Rebuilt on Core 3.0.0 + Route 3.0.0. No breaking changes in Tsak's own API.

Upgrade: package bump, no migrations.

https://dev.to/rinat_kozin_d0a2ef43e7824/why-our-free-was-so-far-behind-pro-and-what-we-just-shipped-in-redbase-300-with-the-actual-sql-i7b

https://redbase.app/architecture

https://github.com/redbase-app/redb/blob/main/CHANGELOG.md
https://github.com/redbase-app/redb-route/blob/main/CHANGELOG.md
https://github.com/redbase-app/redb-tsak/blob/main/CHANGELOG.md

Why our Free was so far behind Pro — and what we just shipped in RedBase 3.0.0 (with the actual SQL)

rinat kozin — Fri, 29 May 2026 23:18:10 +0000

Since the launch posts I keep getting the same question, in DMs, issues, private chats:

"Why is the Free version so different from Pro? It feels like two different products."

It's a fair question, and the honest answer isn't a marketing answer — it's a "this is how the codebase grew over the years" answer. So let me just tell you, and then show you the SQL — both tiers, with the actual parameter values, so you can see exactly what hits the database.

This is one post. There won't be a second one. I'd rather over-explain once than dribble out a series.

30-second background

RedBase is a typed object store. You write a C# class, decorate it with [RedbScheme("name")], the engine syncs the scheme into PostgreSQL or MSSql, and you query with normal LINQ:

[RedbScheme("Employee")]
public class EmployeeProps
{
    public string Name { get; set; } = "";
    public int Age { get; set; }
    public string City { get; set; } = "";
    public Address HomeAddress { get; set; } = new();
    public Dictionary<string, Address> OfficeLocations { get; set; } = new();
    public RedbListItem? Status { get; set; }
    public DateTimeOffset DateCreate { get; set; }
}

var employees = await service.Query<EmployeeProps>()
    .Where(p => p.Age > 30 && p.City == "London")
    .OrderBy(p => p.Name)
    .ToListAsync();

Storage is six tables: _objects, _values, _structures, _schemes, _list_items, _users. One row per object lives in _objects. Each property of that object lives as one or more rows in _values, keyed by (_id_object, _id_structure, _array_index). So filtering by N properties means joining/pivoting N rows back into one logical row per object.

How you do that pivot defines the performance ceiling of the engine. That's the part 3.0.0 fixes for the Free tier.

How we got here — the two paths that existed before 3.0.0

Pro path (since ~2024) — compiled in C

Pro walks the LINQ expression tree in process via ExpressionToSqlCompiler + SqlExpressionVisitor, registers bind variables through SqlParameterCollector, and emits a single PVT (pivot) CTE per query. For the LINQ above, with _id_scheme=42, structure id 101=Age, 102=City:

-- Pro on PostgreSQL — exact text Npgsql sends to the server
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._Long)   FILTER (WHERE v._id_structure = $1 AND v._array_index IS NULL))[1] AS "Age",
    (array_agg(v._String) FILTER (WHERE v._id_structure = $2 AND v._array_index IS NULL))[1] AS "City"
  FROM _values v
  JOIN (SELECT _id FROM _objects WHERE _id_scheme = $3) o ON v._id_object = o._id
  WHERE v._id_structure = ANY($4)
  GROUP BY v._id_object
)
SELECT o.* FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
WHERE pvt."Age" > $5 AND pvt."City" = $6
ORDER BY (array_agg(v._String) FILTER (WHERE ...))[1];

-- bound parameters (NpgsqlParameter, never interpolated into text):
--   $1 = 101         (bigint, structure id of Age)
--   $2 = 102         (bigint, structure id of City)
--   $3 = 42          (bigint, scheme id)
--   $4 = {101, 102}  (bigint[])
--   $5 = 30          (bigint)
--   $6 = 'London'    (text)

What this gets you:

One index hit on (_id_structure, _id_object) — _id_structure = ANY($4) uses the structure-id covering index, narrowing to only the props the query touches.
One GROUP BY pass — FILTER (WHERE …) is PostgreSQL's way of splitting values into columns during aggregation. Each scalar pivot field costs one array_agg aggregator, all running in the same scan. The [1] subscript picks the single element because scalar fields have at most one _values row.
Outer WHERE on flat columns — pvt."Age" > $5 is a normal B-tree comparison on the CTE's projected columns. The optimizer reorders these freely.
Stable parameterized SQL text — same $1..$N placeholders every call, so PostgreSQL's prepared-statement plan cache works. Connection pools love this.

5 fields or 50 — same query shape, same cost class.

And here is the same query through Free 3.0.0 on PostgreSQL — byte-for-byte the same shape:

-- Free 3.0.0 on PostgreSQL — emitted by pvt_build_query_sql(scheme, facets_jsonb)
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._Long)   FILTER (WHERE v._id_structure = 101 AND v._array_index IS NULL))[1] AS "Age",
    (array_agg(v._String) FILTER (WHERE v._id_structure = 102 AND v._array_index IS NULL))[1] AS "City"
  FROM _values v
  JOIN (SELECT _id FROM _objects WHERE _id_scheme = 42) o ON v._id_object = o._id
  WHERE v._id_structure IN (101, 102)
  GROUP BY v._id_object
)
SELECT o.* FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
WHERE pvt."Age" > 30 AND pvt."City" = 'London';

-- The literals you see here are NOT string-concatenated user input.
-- They are emitted by format(..., %L) with explicit type casts inside
-- the plpgsql builder. The C# caller made two parameterized roundtrips:
--   1) SELECT pvt_build_query_sql($1, $2::jsonb, $3, $4)   -- returns SQL text
--        with ($1=schemeId, $2=facets, $3=limit, $4=offset) as Npgsql parameters
--   2) EXECUTE the returned text on the connection → collect _id values
--   3) SELECT * FROM get_objects_json($1::bigint[], $2)    -- hydrate by ids
--        with ($1={...matched ids...}, $2=maxDepth) as Npgsql parameters
-- See the SQL-injection section below for the full chain.

Same CTE, same array_agg FILTER, same outer flat WHERE. The only structural difference: the SQL text is built once per call by pvt_build_query_sql inside the database, so the outer EXECUTE runs a unique string each call — values come baked in as %L-quoted literals with type casts (30, 'London') rather than as $N placeholders. That has plan-cache implications versus Pro (the SQL text varies, so PG can't reuse a plan across calls with different values), but the index path and join shape the planner picks are identical. For the parameterized story, see how this gets called from any language a few sections down.

Free path (until 3.0.0) — interpreted on the database side

The Free path serialized the LINQ filter into a JSON facet structure, shipped it to a plpgsql function, and that function built dynamic SQL inside the database. For the same LINQ above:

// C# side just packs the facets and calls one function
var facets = new {
    @and = new object[] {
        new { Age  = new { gt = 30 } },
        new { City = new { eq = "London" } },
    }
};
await conn.QueryAsync("SELECT * FROM search_objects_with_facets($1, $2)",
                      schemeId, facets);

The function then emitted, for those exact arguments:

-- Old Free on PostgreSQL — N props in WHERE → N correlated EXISTS
SELECT o.*
FROM _objects o
WHERE o._id_scheme = 42
  AND EXISTS (
    SELECT 1 FROM _values v
    WHERE v._id_object = o._id
      AND v._id_structure = 101
      AND v._Long > 30
  )
  AND EXISTS (
    SELECT 1 FROM _values v
    WHERE v._id_object = o._id
      AND v._id_structure = 102
      AND v._String = 'London'
  );

PostgreSQL optimizes correlated EXISTS well when the right index is there, so this is fine at 1–3 props. By 10 props the planner is doing real work to choose join order. By 30 props you're seeing query times you don't want. (For curiosity: the legacy path stays in the database under the name search_objects_with_facets() for back-compat — old callers keep working.)

On MSSql Free the picture was uglier still — a wide-CASE inline pivot that hadn't received the same iterations as the PG side. Different SQL shape from PG, different code path inside the library, different bugs. The two Free implementations had drifted.

Why the gap existed for so long

I built the Pro engine because we needed it. We use Pro internally — that's what runs the production workloads. The Free path kept working for its users, but parity was always "next quarter." It's not a single feature, it's:

pivot CTE generation for both dialects;
base-field pushdown into the inner _objects subquery;
nested-dict accessor (Field[key].Child);
ListItem .Value / .Alias via a single JOIN;
GroupBy, HAVING, ArrayGroupBy, DistinctBy, Sql.Function whitelist, $expr trees;
null semantics, $exists / $notNull;
a filter-splitting optimizer that decides what's a Shape A (pure base), B (narrow) or C (wide pivot) query;
and all of it round-tripping through 200+ integration tests per backend.

Spread that across two databases and you understand why it kept slipping. The interest spike from the launch posts is what pushed me to drop the half-written stuff and ship this. It's not finished-finished — that's why it's an OSS release instead of a private polish round.

What 3.0.0 actually changes

The headline: Free and Pro now emit the same PVT CTE shape, on both PostgreSQL and MSSql.

1. MSSql Free hit full v2-pvt parity — 145/145

The old MSSql Free path is gone. The new one is a 27-file SQL module under redb.MSSql/sql/v2-pvt/, assembled by an MSBuild target into a single pvt_bundle.sql resource embedded in RedBase.MSSql.dll:

00_module_init.sql           -- version sentinel, drop-and-replace bootstrap
10_pvt_field_collection.sql  -- walks the facet JSON, harvests structure ids
13_pvt_condition.sql         -- per-field WHERE fragments
14_pvt_where.sql             -- recursive $and/$or/$expr walker
15_pvt_order.sql             -- ORDER BY building (incl. $expr ordering)
16_pvt_split.sql             -- Shape A/B/C classifier, pushdown engine
17_pvt_expr.sql              -- $expr classifier + scalar expression compiler
20_pvt_build_query_sql.sql   -- the entry point — returns the final SQL text
99_smoke_auto.sql            -- 195 PASS / 0 FAIL / 1 SKIP regression suite
... (and friends)

The MSSql dialect uses MAX(CASE WHEN …) instead of array_agg FILTER (SQL Server has no FILTER clause), but the rest of the shape is the same. Same LINQ as above, on MSSql Free, becomes:

-- Free MSSql 3.0.0 — emitted by the T-SQL builder under [dbo].[pvt_build_query_sql]
WITH pvt_cte AS (
  SELECT v.[_id_object],
    MAX(CASE WHEN v.[_id_structure] = 101 AND v.[_array_index] IS NULL THEN v.[_Long]   END) AS [Age],
    MAX(CASE WHEN v.[_id_structure] = 102 AND v.[_array_index] IS NULL THEN v.[_String] END) AS [City]
  FROM [_values] v
  JOIN (SELECT [_id] FROM [_objects] WHERE [_id_scheme] = 42) o
    ON v.[_id_object] = o.[_id]
  WHERE v.[_id_structure] IN (101, 102)
  GROUP BY v.[_id_object]
)
SELECT o.* FROM [_objects] o
JOIN pvt_cte pvt ON o.[_id] = pvt.[_id_object]
WHERE pvt.[Age] > 30 AND pvt.[City] = N'London';

-- Same idea as the PG Free block above: literals are inlined by the T-SQL
-- builder via QUOTENAME() for identifiers and quoted-literal emission for
-- values (numeric literals stay bare, strings become N'...' with embedded
-- quotes escaped). The C# caller made two parameterized roundtrips:
--   1) EXEC sp_executesql N'SELECT [dbo].[pvt_build_query_sql](@scheme, @facets, @limit, @offset)',
--        N'@scheme bigint, @facets nvarchar(max), @limit int, @offset int', ...   -- returns SQL text
--   2) EXEC sp_executesql @sql                                                    -- collect _id values
--   3) SELECT * FROM [dbo].[get_objects_json](@ids, @maxDepth)                    -- hydrate by ids
-- User input never touches a SQL parser unquoted. The SQL-injection section
-- below walks the chain.

MAX(CASE WHEN ...) is the SQL Server idiom that mirrors array_agg FILTER: NULLs are ignored by aggregates, so the CASE acts as a "pass through if matching, otherwise null" gate. Same one-pass GROUP BY, same outer WHERE on flat columns. (Unlike Pro — which sends a parameterized statement with @p1..@pN placeholders and benefits from SQL Server's plan cache — Free's text varies per call, so plan reuse depends on SQL Server's auto-parameterization. Shape and index path are identical to Pro either way.)

Everything PG Free had now works identically on MSSql Free: flat + tree queries, scalar / array / dict fields, nested-dict Field[key].Child, ListItem joins for .Id / .Value / .Alias, same-scheme nested POCO compound paths, OrderBy / Take / Skip / DistinctBy, full GroupBy with HAVING, ArrayGroupBy via OUTER APPLY, array aggregates, Sql.Function whitelist, $expr, null semantics.

2. Auto-deploy of the v2-pvt bundle

ISqlDialect got a new method:

public interface ISqlDialect
{
    // ... existing dialect surface ...
    string? Query_PvtRequiredVersion();   // semver the embedded bundle ships
}

RedbServiceBase.EnsurePvtModuleDeployedAsync runs on InitializeAsync():

var required = Dialect.Query_PvtRequiredVersion();
if (required is null) return;                 // dialect doesn't use v2-pvt

var deployed = await Context.ExecuteScalarAsync<string?>(
    Dialect.SelectPvtModuleVersionSql());     // calls pvt_module_version()

if (string.Equals(deployed, required, StringComparison.Ordinal))
    return;                                    // exact match — already deployed

Logger?.LogInformation("v2-pvt mismatch (deployed={D}, required={R}). Applying bundle.",
                       deployed, required);
await Context.ExecuteNonQueryAsync(ReadEmbeddedBundle());

The match is exact-string, not semver-numeric. Any change to any of the 27 source files bumps the bundle version, the MSBuild target regenerates pvt_bundle.sql on the next build, and on next service startup the new bundle gets applied. No DBA in the loop, no "did you forget to run the migration?" tickets.

(One MSBuild gotcha cost me half a day: declaring <EmbeddedResource Include="sql\v2-pvt\pvt_bundle.sql" /> silently renames the manifest resource from redb.MSSql.sql.v2-pvt.pvt_bundle.sql to redb.MSSql.sql.v2_pvt.pvt_bundle.sql — dashes become underscores. GetManifestResourceStream returns null and you stare at it for a while. Fix: pin <LogicalName>redb.MSSql.sql.v2-pvt.pvt_bundle.sql</LogicalName> explicitly. Free tip if you ever ship SQL through embedded resources.)

3. Base-field pushdown — the 894 ms → 11 ms one

This is the regression that originally motivated 2.0.1. When a query mixes a base-field predicate (on _objects columns) with a props predicate:

var children = await service.Query<EmployeeProps>()
    .WhereRedb(o => o._id_parent == 555)   // base field, manager id 555
    .Where(p => p.Age > 30)                 // props field
    .ToListAsync();

The naive layout puts the base predicate in the outer WHERE — that's what 2.0.0 did:

-- Bad: 894 ms on a scheme with millions of _values rows
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._Long) FILTER (WHERE v._id_structure = $1))[1] AS "Age"
  FROM _values v
  JOIN _objects o ON v._id_object = o._id
  WHERE o._id_scheme = $2 AND v._id_structure = ANY($3)
  GROUP BY v._id_object
)
SELECT o.* FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
WHERE o._id_parent = $4    -- outer: applies AFTER the CTE pivoted the entire scheme
  AND pvt."Age" > $5;

-- $1=101, $2=42, $3={101}, $4=555, $5=30

PostgreSQL aggregates _values for every employee in the scheme and only then narrows by _id_parent. Self-inflicted full pivot.

3.0.0 (both Free and Pro, both dialects) classifies the base predicate at compile time and injects it into the inner _objects subquery of the PVT CTE:

-- Good: 11 ms
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._Long) FILTER (WHERE v._id_structure = $1))[1] AS "Age"
  FROM _values v
  JOIN (SELECT _id FROM _objects
        WHERE _id_scheme = $2
          AND _id_parent = $3   -- pushed in
       ) o ON v._id_object = o._id
  WHERE v._id_structure = ANY($4)
  GROUP BY v._id_object
)
SELECT o.* FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
WHERE pvt."Age" > $5;

-- $1=101, $2=42, $3=555, $4={101}, $5=30

Free 3.0.0 emits the same shape — here it is on PostgreSQL, with the values baked in by pvt_split_filter:

-- Free 3.0.0 on PostgreSQL — pushdown identical to Pro
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._Long) FILTER (WHERE v._id_structure = 101))[1] AS "Age"
  FROM _values v
  JOIN (SELECT _id FROM _objects
        WHERE _id_scheme = 42
          AND _id_parent = 555           -- pushed in by pvt_split_filter
       ) o ON v._id_object = o._id
  WHERE v._id_structure IN (101)
  GROUP BY v._id_object
)
SELECT o.* FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
WHERE pvt."Age" > 30;

And on MSSql Free 3.0.0 — again, literals inlined by the T-SQL builder, not parameters:

-- Free MSSql 3.0.0 — pushdown via the same classifier, MAX/CASE pivot, values inlined
WITH pvt_cte AS (
  SELECT v.[_id_object],
    MAX(CASE WHEN v.[_id_structure] = 101 AND v.[_array_index] IS NULL THEN v.[_Long] END) AS [Age]
  FROM [_values] v
  JOIN (SELECT [_id] FROM [_objects]
        WHERE [_id_scheme] = 42
          AND [_id_parent] = 555         -- pushed in by the T-SQL split classifier
       ) o ON v.[_id_object] = o.[_id]
  WHERE v.[_id_structure] IN (101)
  GROUP BY v.[_id_object]
)
SELECT o.* FROM [_objects] o
JOIN pvt_cte pvt ON o.[_id] = pvt.[_id_object]
WHERE pvt.[Age] > 30;

The inner subquery resolves via the (_id_scheme, _id_parent) covering index, returns ~N matching _ids, and the pivot only sees _values rows for those N objects. Pro got this in 2.0.1; 3.0.0 brings the same to Free through pvt_split_filter and the pvt_expr_is_base_only classifier in 17_pvt_expr.sql.

4. Nested-dict accessor short-circuit

For Dictionary<string, T> fields, Where(o => o.OfficeLocations["HQ"].City == "New York") builds the dict-keyed pivot column in the CTE. There's no separate _dict_key column in _values — the existing _array_index slot (text) doubles as the dict key for dictionary fields (it stays an integer-as-text for arrays, holds the key for dicts, is NULL for scalars):

(array_agg(v._String) FILTER (
  WHERE v._id_structure = 117    -- structure id of City inside OfficeLocations
    AND v._array_index = 'HQ'    -- _array_index doubles as the dict key
))[1] AS "OfficeLocations[HQ].City"

The bug fixed in this cycle (MSSql 0.1.3, PG 0.6.1 earlier): the outer WHERE was also emitting a separate EXISTS over _values to re-check the same dict key, even though the CTE had already done that work. The six-line fix in 13_pvt_condition.sql makes the outer WHERE just reference the pivot column directly:

-- Before
WHERE EXISTS (
  SELECT 1 FROM _values v
  WHERE v._id_object = o._id
    AND v._id_structure = 117
    AND v._array_index = 'HQ'
    AND v._String = 'New York'
)

-- After
WHERE pvt."OfficeLocations[HQ].City" = $4    -- $4='New York'

One predicate, no subquery, the optimizer can reorder it freely with the rest of the WHERE.

5. What landed in Pro this cycle

While Free was catching up, Pro added its own things (the version is 3.0.0 for both):

GroupBy + HAVING in Pro. HavingAsync existed in Free since 1.2.x but had no Pro counterpart. Now:

var stats = await service.Query<EmployeeProps>()
    .GroupBy(p => p.Department.Value)
    .Where(g => g.Count() > 10 && g.Average(p => p.Age) < 40)   // HAVING
    .Select(g => new { Dept = g.Key, N = g.Count() })
    .ToListAsync();

→

WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._listitem) FILTER (WHERE v._id_structure = $1))[1] AS "Department_id",
    (array_agg(v._Long)     FILTER (WHERE v._id_structure = $2))[1] AS "Age"
  FROM _values v
  JOIN (SELECT _id FROM _objects WHERE _id_scheme = $3) o ON v._id_object = o._id
  WHERE v._id_structure = ANY($4)
  GROUP BY v._id_object
)
SELECT li."_value" AS "Dept", COUNT(*) AS "N"
FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
LEFT JOIN _list_items li ON li._id = pvt."Department_id"
GROUP BY li."_value"
HAVING COUNT(*) > $5 AND AVG(pvt."Age") < $6;

-- $1=130, $2=101, $3=42, $4={130,101}, $5=10, $6=40

The Free side has had HavingAsync since 1.2.x — here's the same LINQ through Free 3.0.0 on PostgreSQL for parity, so you can see they really do meet in the middle now:

-- Free 3.0.0 PG — same HAVING shape, values inlined by pvt_build_query_sql
WITH pvt_cte AS (
  SELECT v._id_object,
    (array_agg(v._listitem) FILTER (WHERE v._id_structure = 130))[1] AS "Department_id",
    (array_agg(v._Long)     FILTER (WHERE v._id_structure = 101))[1] AS "Age"
  FROM _values v
  JOIN (SELECT _id FROM _objects WHERE _id_scheme = 42) o ON v._id_object = o._id
  WHERE v._id_structure IN (130, 101)
  GROUP BY v._id_object
)
SELECT li."_value" AS "Dept", COUNT(*) AS "N"
FROM _objects o
JOIN pvt_cte pvt ON o._id = pvt._id_object
LEFT JOIN _list_items li ON li._id = pvt."Department_id"
GROUP BY li."_value"
HAVING COUNT(*) > 10 AND AVG(pvt."Age") < 40;

And on MSSql Free 3.0.0 — same shape, literals inlined:

-- Free MSSql 3.0.0 — same HAVING shape, MAX/CASE pivot, values inlined by the T-SQL builder
WITH pvt_cte AS (
  SELECT v.[_id_object],
    MAX(CASE WHEN v.[_id_structure] = 130 THEN v.[_listitem] END) AS [Department_id],
    MAX(CASE WHEN v.[_id_structure] = 101 THEN v.[_Long]     END) AS [Age]
  FROM [_values] v
  JOIN (SELECT [_id] FROM [_objects] WHERE [_id_scheme] = 42) o
    ON v.[_id_object] = o.[_id]
  WHERE v.[_id_structure] IN (130, 101)
  GROUP BY v.[_id_object]
)
SELECT li.[_value] AS [Dept], COUNT(*) AS [N]
FROM [_objects] o
JOIN pvt_cte pvt ON o.[_id] = pvt.[_id_object]
LEFT JOIN [_list_items] li ON li.[_id] = pvt.[Department_id]
GROUP BY li.[_value]
HAVING COUNT(*) > 10 AND AVG(pvt.[Age]) < 40;

33/33 HAVING + 6/6 no-HAVING in GroupByHavingTestsBase, green on PG.Pro and MSSql.Pro — and identical row counts on the Free side.

ArrayGroupBy unified across all four tiers — GroupBy(items => items.SelectMany(o => o.Skills)) works identically on PG Free, PG.Pro, MSSql Free, MSSql.Pro.

MSSql.Pro AggregateBatch parity with PG.Pro — non-numeric MinAsync / MaxAsync (over string/DateTime/Guid) and a Where(...) filter inside a batch aggregation now produce the same plan shape on MSSql.Pro as PG.Pro.

Plus a stack of bug-fixes documented in CHANGELOG.md.

"Wait — Free builds SQL dynamically inside plpgsql. What about SQL injection?"

Right question. If you skimmed the Free SQL above and noticed it's EXECUTE-ing a dynamically-built string inside a database function — your instinct is correct, that would be a problem in a naively-written generator. Here's what actually guards against it.

Pro side (C#) — boring and safe

Pro builds parameterized SQL via SqlParameterCollector. Every value the user expression captured (30, "London", managerId) becomes an NpgsqlParameter / SqlParameter. The text Npgsql sends to PostgreSQL contains $1..$N placeholders only; values travel out-of-band through the wire protocol and never see a SQL parser. No template, no concatenation, no format(). There's literally no path for an injection because there's no string-to-SQL bridge for values.

Free side on PostgreSQL (plpgsql) — three layers, on purpose

Free has it harder than Pro because the SQL builder runs inside the database, so the values arrive baked into the JSON. The defenses, layer by layer:

1. Values pass through format(..., %L) with explicit type casts.

%L is PostgreSQL's literal-quoting format specifier — same semantics as quote_literal(). It single-quotes the value, escapes embedded quotes, and returns a SQL-safe literal. Example from 04_pvt_inner_condition.sql:

-- The leaf emitter for "Long $gt N" looks like this:
RETURN format('fv._Long %s %L::bigint', op_symbol, operator_value);

If a malicious payload arrives as operator_value = "1; DROP TABLE _objects --", %L produces:

fv._Long > '1; DROP TABLE _objects --'::bigint

The ::bigint cast then fails at parse time with a normal type error. The single quotes from %L make the injection inert; the type cast makes it a hard error rather than silent data corruption. Every value branch in 04_pvt_inner_condition.sql uses this pattern: %L::bigint, %L::numeric, %L::timestamptz, %L::uuid, %L::boolean, %L::interval. Strings use plain %L (which is '…'-quoting), and any further use as text is still inside single quotes.

2. Identifiers come from the database, not from the JSON.

The user's JSON facets refer to fields by name ("Age", "OfficeLocations[HQ].City"). The builder doesn't concatenate that string into the SQL. Instead, pvt_field_collection looks the name up in _structures for the queried scheme — by joining _structures._name = $jsonKey AND _structures._id_scheme = $scheme. If the name doesn't exist, the field is rejected. If it does exist, what gets emitted is the matched _id_structure (a bigint, always safe) and a pivot column alias built with quote_ident(structure_name_from_db) or %I. So:

The structure id is a number from the DB.
The pivot column name is quote_ident'd, so "weird name with quotes" becomes a double-quoted SQL identifier.
Reserved bases (0$:id, 0$:parent_id, etc.) are dispatched through a fixed CASE — unknown bases raise:

  RAISE EXCEPTION 'Unknown RedbObject base field: "%" ...'

No path lets arbitrary text become an unquoted identifier.

3. Operator names are a fixed whitelist.

$eq, $gt, $lt, $ne, $in, $like, $ilike, $arrayContains, $expr, etc. are matched by a CASE/IF tree in 04_pvt_inner_condition.sql and friends. Unknown operators don't fall through to anything — they RAISE EXCEPTION:

RAISE EXCEPTION 'pvt_build_agg_expr: unsupported aggregate "%"', v_op;

Same for Sql.Function — only names in the whitelist (COALESCE, LOWER, UPPER, …) survive; everything else raises.

4. The final EXECUTE evaluates a string built only from the three pieces above.

So even though EXECUTE is involved, every byte of that string came from either:

a quote_literal'd (%L) value with a type cast, or
a quote_ident'd (%I) identifier sourced from _structures by id lookup, or
a hardcoded operator template chosen by a whitelist switch.

That's three independent gates, and any of them is sufficient to defeat injection. The plpgsql generator is paranoid by design — format/%L/%I are used uniformly, not as a one-off. The 99-test smoke suite (99_smoke_auto.sql) includes adversarial payloads ("; DROP TABLE …, embedded quotes, type-mismatched literals) and expects parse errors or rejection, not successful execution.

If you want to audit the PG side: every emitter is in 04_pvt_inner_condition.sql, 05_pvt_single_facet.sql, 13_pvt_condition.sql. Grep for format( — every value site has %L and a cast, every identifier site has %I or quote_ident.

Free side on MSSql (T-SQL) — the same three layers, different primitives

SQL Server has no format(..., %L/%I) and no quote_literal/quote_ident shorthand, so the MSSql builder under redb.MSSql/sql/v2-pvt/ implements each layer with the T-SQL primitives that are available. Same three gates, just spelled differently.

1. Values are quoted with REPLACE(..., '''', '''''') and/or validated with TRY_CAST before they get inlined.

For strings (including dict keys and $expr literals) the builder wraps the value in N'…' after doubling embedded single quotes — the SQL Server equivalent of quote_literal. From the actual pivot builder (pvt_bundle.sql, the dict-key branch):

-- Real emitter for dict-key match in the CTE
-- (the dict key goes into _values._array_index — same slot used for array indices)
SET @dict_key_literal =
    N'N''' + REPLACE(@dict_key, N'''', N'''''') + N'''';
-- Then concatenated into:
--   ... AND v.[_array_index] = N'HQ' THEN v.[_String] END) AS [...]

If @dict_key = "HQ'; DROP TABLE _values; --", the REPLACE doubles the embedded quote to '', and the emitted SQL becomes:

v.[_array_index] = N'HQ''; DROP TABLE _values; --'

The whole payload stays a single string literal. The tail of the payload never escapes the quotes, so it never gets executed.

For numerics the builder doesn't even concatenate raw user text — it first parses it with TRY_CAST and only inlines the parsed value if the parse succeeded. From 06_pvt_hierarchical.sql:

DECLARE @ha_id BIGINT = TRY_CAST(@ha_raw AS BIGINT);
IF @ha_id IS NOT NULL
    SET @result += N' AND dbo.pvt_is_descendant_of(' + @alias + N'.[_id], '
                 + CAST(@ha_id AS NVARCHAR(20)) + N') = 1';
-- If @ha_id is NULL the clause is silently dropped — bad input never
-- becomes SQL text. The only thing that ever gets inlined is a real BIGINT.

TRY_CAST returns NULL rather than raising on bad input, and the builder simply omits the clause in that case — so "1; DROP TABLE _objects --" never reaches the SQL text. The behaviour is fail-closed (no clause emitted) rather than fail-loud (no exception thrown); the predicate effectively becomes a no-op. Same pattern for WhereLevel (TRY_CAST AS INT), WhereHasDescendant, WhereContainsObject, and the other base-id predicates. For dates it's TRY_CONVERT(datetimeoffset, …), for GUIDs it's TRY_CONVERT(uniqueidentifier, …) — quote-then-typed-parse, drop-on-fail.

2. Identifiers come from _structures via QUOTENAME(), never from raw JSON.

Every pivot column alias, every projection alias, every table/column name in the dynamic SQL goes through QUOTENAME(). From the pivot CTE builder:

DECLARE @alias NVARCHAR(420) = QUOTENAME(@field_name);  -- @field_name comes from _structures
-- ...
RETURN N'o.' + QUOTENAME(@col) + N' AS ' + @alias;

QUOTENAME('weird]name') returns [weird]]name] — embedded ] is doubled, the result is always a single safely-bracketed identifier. As on the PG side, the source of @field_name is a _structures._name row matched by (_id_scheme = @scheme AND _name = @json_key) — if the JSON refers to a field the queried scheme doesn't have, the lookup returns nothing and the field is rejected with a RAISERROR before any SQL text is built.

For base-fields (0$:id, 0$:parent_id, 0$:scheme_id, …) there's a fixed CASE; unknown bases RAISERROR with the same "Unknown RedbObject base field" message as the PG side.

3. Operator names are a fixed CASE/IF whitelist with RAISERROR on miss.

Same logic as PG: $eq, $gt, $lt, $in, $like, $arrayContains, $expr, etc. are matched by a CASE tree. Anything not on the list raises:

RAISERROR(N'pvt: unsupported operator "%s"', 16, 1, @op);

Sql.Function calls go through the same whitelist — COALESCE, LOWER, UPPER, LEN, LEFT, RIGHT, ISNULL, etc. Unknown function names raise; the user can't smuggle xp_cmdshell through Sql.Function<int>("xp_cmdshell", "...") because that name isn't in the CASE.

4. The dynamic SQL is built only from the three pieces above and executed with sp_executesql.

Final execution is EXEC sp_executesql @sql (with parameterized @scheme_id, @limit, @offset etc. as sp_executesql arguments, not concatenated). Every byte of @sql came from either:

a REPLACE-quoted string literal in N'…', or
a TRY_CAST-validated typed value inlined as its parsed form, or
a QUOTENAME-bracketed identifier sourced from _structures by id lookup, or
a hardcoded operator template chosen by a whitelist CASE.

The 99_smoke_auto.sql regression suite on MSSql includes the same adversarial payloads as the PG suite — '; DROP TABLE …, embedded quotes, ] in field names, type-mismatched literals, unknown operators — and expects each one to be either rejected with RAISERROR (operators / unknown bases / unknown identifiers), silently dropped from the predicate (typed-value parse failures), or come out the other side as an inert quoted literal that does nothing (string values).

Summary

Layer	PG Free emits via	MSSql Free emits via
String values	`format('… %L', val)`	`N'' + REPLACE(val, '''', '''''') + N''`
Numeric / date / GUID values	`%L::bigint` / `%L::numeric` / `%L::timestamptz` / `%L::uuid` (parse-or-die at runtime)	`TRY_CAST(... AS BIGINT)` / `TRY_CONVERT(datetimeoffset, ...)` / `TRY_CONVERT(uniqueidentifier, ...)` (parse-or-drop-clause before inline)
Identifiers	`%I` / `quote_ident(name_from__structures)`	`QUOTENAME(name_from__structures)`
Operators / function names	CASE whitelist → `RAISE EXCEPTION`	CASE whitelist → `RAISERROR`
Final execution	`EXECUTE` of the assembled string	`EXEC sp_executesql` of the assembled string

Same three independent gates on both databases. Any one of them is sufficient to defeat injection; the suite tests all three.

If you find a leak in either dialect, file an issue with the JSON payload that triggers it. I'll treat it as a security bug, not a feature request.

The polyglot facet API — Free's one structural advantage

A side-effect of Free's SQL-side builder: it's accessible from any language. Pro compiles in C#, which is its strength but also its limitation — you need a .NET process. Free compiles in SQL, so the same builder C# Free clients hit is callable from any driver that can run SQL.

The shipped surface is two functions, not one:

Function	Input	Output
`pvt_build_query_sql(scheme_id, facets jsonb, limit, offset, order jsonb, max_depth, …)`	facets	the assembled `SELECT _id FROM …` as `text`
`get_objects_json(ids bigint[], max_depth integer DEFAULT 10)`	matched ids	table of `(Id bigint, JsonData text)` with fully hydrated objects

The honest flow is therefore two SQL roundtrips: build → EXECUTE the returned text → hydrate. The 10-line plpgsql wrapper below collapses that into a single call you can ship into your DB once and then call from any language:

-- one-time setup: paste into your DB as a wrapper of the two shipped functions
CREATE OR REPLACE FUNCTION redb_run_facets(
    p_scheme_id bigint,
    p_facets    jsonb   DEFAULT NULL,
    p_limit     integer DEFAULT NULL,
    p_offset    integer DEFAULT 0,
    p_order     jsonb   DEFAULT NULL,
    p_max_depth integer DEFAULT 10
) RETURNS TABLE("Id" bigint, "JsonData" text)
LANGUAGE plpgsql STABLE AS $$
DECLARE v_sql text; v_ids bigint[];
BEGIN
    v_sql := pvt_build_query_sql(p_scheme_id, p_facets, p_limit, p_offset, p_order, p_max_depth);
    EXECUTE 'SELECT array_agg(_id) FROM (' || v_sql || ') t' INTO v_ids;
    IF v_ids IS NULL THEN RETURN; END IF;
    RETURN QUERY SELECT g."Id", g."JsonData" FROM get_objects_json(v_ids, p_max_depth) g;
END $$;

With that wrapper in place:

# Python — psycopg
import psycopg, json

facets = {
    "$and": [
        {"Age":  {"$gt": 30}},
        {"City": {"$eq": "London"}},
    ]
}

with psycopg.connect(DSN) as conn, conn.cursor() as cur:
    cur.execute(
        'SELECT "JsonData" FROM redb_run_facets(%s, %s::jsonb, %s, %s)',
        (scheme_id, json.dumps(facets), 100, 0),    # limit, offset
    )
    employees = [row[0] for row in cur.fetchall()]
    # each row is JSON text — nested objects, arrays, dictionaries,
    # ListItem references — all fully reconstructed.

// Node — pg
const facets = { $and: [{ Age: { $gt: 30 } }, { City: { $eq: 'London' } }] };
const { rows } = await client.query(
  'SELECT "JsonData" FROM redb_run_facets($1, $2::jsonb, $3, $4)',
  [schemeId, JSON.stringify(facets), 100, 0],
);
const employees = rows.map(r => JSON.parse(r.JsonData));

// Go — pgx
facets := []byte(`{"$and":[{"Age":{"$gt":30}},{"City":{"$eq":"London"}}]}`)
rows, err := conn.Query(ctx,
    `SELECT "JsonData" FROM redb_run_facets($1, $2::jsonb, $3, $4)`,
    schemeID, facets, 100, 0,
)
// scan each row into a json.RawMessage

// Java — JDBC
String facets = "{\"$and\":[{\"Age\":{\"$gt\":30}},{\"City\":{\"$eq\":\"London\"}}]}";
try (PreparedStatement ps = conn.prepareStatement(
        "SELECT \"JsonData\" FROM redb_run_facets(?, ?::jsonb, ?, ?)")) {
    ps.setLong(1, schemeId);
    ps.setString(2, facets);
    ps.setInt(3, 100);
    ps.setInt(4, 0);
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            String hydratedJson = rs.getString(1);
        }
    }
}

-- raw psql — same engine, no driver at all
SELECT "JsonData"
FROM redb_run_facets(
    42::bigint,
    '{"$and":[{"Age":{"$gt":30}},{"City":{"$eq":"London"}}]}'::jsonb,
    100, 0
);

If you'd rather skip the wrapper and call the shipped functions directly, the two-roundtrip pattern is:

-- 1. build the query text
SELECT pvt_build_query_sql(42, '{"$and":[…]}'::jsonb, 100, 0) AS sql;
-- 2. EXECUTE the returned text on the client → collect _id values
-- 3. hydrate
SELECT * FROM get_objects_json(ARRAY[101,102,103]::bigint[], 10);

The JSON facet schema is a stable contract — see FREE-OVER-PRO.md for the full operator list. Tuple-key dictionaries, nested RedbObject<T> references, RedbListItem references with .Id/.Value/.Alias — all reconstruct correctly in the JSON get_objects_json emits. No schema knowledge needed on the client side.

And the injection story above applies the same way here — your psycopg/pgx/JDBC driver binds the JSON as a jsonb parameter, so even your facet payload doesn't touch a SQL parser until it's already inside the parameterized builder.

This is Free-only by design. Pro's edge has always been the CLR-side compiled pipeline plus parallel materialization (ProLazyPropsLoader does 2 bulk _values SELECTs, indexes them into ILookup, and ProPropsMaterializer runs Parallel.ForEach to assemble 20+ value types, nested objects, arrays, dictionaries, ListItem refs into typed RedbObject<T> — all CPU-bound, zero further DB access). That stays where it is.

The honest matrix

Capability	Free 3.0.0	Pro 3.0.0
Query shape (PVT CTE, base pushdown, MAX/CASE ↔ array_agg)	Same	Same
`GroupBy + HAVING`	✓	✓
`ArrayGroupBy` (unnest / OUTER APPLY)	✓	✓
`DistinctBy`, `Sql.Function` (whitelist), `$expr` trees	✓	✓
Tree queries (`WhereHasAncestor`, `WhereLevel`, etc.)	✓	✓
Window functions (`Lag`/`Lead`/`Rank`/`DenseRank`)	✓	✓
Polyglot facet API (Python / Node / Go / Java / raw SQL)	✓	—
Compiled in C# (no JSON intermediate)	—	✓
Parallel CLR materialization (`Parallel.ForEach`)	—	✓
Bulk save via `COPY` protocol	—	✓
Hash-based `ChangeTracking` (diff only what changed)	—	✓
Combined `GroupBy` + window + `AggregateBatch`	✓	✓

Two things to be honest about:

Free has higher latency on full-object load than Pro — get_object_json builds JSON in plpgsql and the client deserializes. Pro's bulk-+-parallel materialization is a real win when you're loading thousands of complex objects with 20+ nested fields each.
Pro still has features Free won't get — parallel bulk materialization (ProLazyPropsLoader + ProPropsMaterializer) and hash-based ChangeTracking remain Pro-only. The query shape itself is now identical.

But the query shape — the part that determines whether the database uses your indexes properly, whether the plan caches, whether 30 props in a WHERE becomes 30 EXISTS or one pivot — that's the same in both tiers now.

Migration notes

If you're on 2.0.x Free, upgrading to 3.0.0:

Update packages — RedBase.Core, RedBase.Postgres / RedBase.MSSql to 3.0.0.
First startup applies the v2-pvt bundle automatically. The new module is additive at the C# API level — your existing LINQ-style queries just compile through the new path. Note: the legacy plpgsql function search_objects_with_facets() (used only by pre-2.0 raw-SQL callers) is no longer installed by redb_init.sql — it lives under redb.Postgres/sql/deprecated/ if you still need it; paste it manually before upgrading if you had direct SQL callers.
Pre-existing config flag is now honored. DefaultStrictDeleteExtra in built-in presets Development, HighPerformance, Migration was set to false but silently ignored before 3.0.0. It now actually works — meaning those presets will no longer auto-delete _structures rows for fields removed from your Props class on startup. If you were relying on the old (silently-broken) behavior, set c.DefaultStrictDeleteExtra = true explicitly.
MSSql Free users: the wide-CASE inline pivot is gone. If you had query-text-matching log scrapers, the new shape is WITH pvt_cte AS (... MAX(CASE WHEN _id_structure = @p1 AND _array_index IS NULL THEN _X END) ...) SELECT o.* FROM _objects o JOIN pvt_cte pvt ON ....

No source-level breaking API changes. No data migrations. If you've never touched the SQL surface directly, you can upgrade and not notice anything except your slow queries getting faster.

Known gaps I'd like help finding

Nested-field cross-scheme JOIN — Where(o => o.CurrentProject.Props.Name == "X") where CurrentProject is a RedbObject<OtherScheme> reference. Free PVT rejects the path; Pro SchemeFieldResolver throws. Needs new infrastructure on both sides. Tracked in FREE-OVER-PRO.md §2 #6b.
MSSql Free is fresh. Two weeks of intensive testing, not two years. EXPLAIN traces and failing repros are very welcome.
Polyglot facet API documentation is thinner than the C# API. The operator surface is stable (it's what the C# parser emits), but it's not yet a documented wire-protocol RFC.

There will be follow-up fixes after this post lands — that's expected. If you hit something, please open a thread in GitHub Discussions rather than sitting on it.

Try it

# Free
dotnet add package RedBase.Core      --version 3.0.0
dotnet add package RedBase.Postgres  --version 3.0.0     # or RedBase.MSSql

# Pro (commercial)
dotnet add package RedBase.Core.Pro       --version 3.0.0
dotnet add package RedBase.Postgres.Pro   --version 3.0.0   # or RedBase.MSSql.Pro

Repo: https://github.com/redbase-app/redb
Full 3.0.0 changelog: CHANGELOG.md
Architecture deep-dive (with the same LINQ→SQL examples): https://redbase.app/architecture
Issues / bug reports: https://github.com/redbase-app/redb/issues — please cite the SQL and the dialect.

If you read all the way to here, thank you. Tell me what's wrong with it.

From Closed Internal Stack to Open-Source Ecosystem: I Finally Shipped Three Years of .NET Infrastructure

rinat kozin — Sat, 23 May 2026 16:07:54 +0000

This is a submission for the
GitHub Finish-Up-A-Thon Challenge

Why this exists (the actual pain)

Before the architecture talk, the why. Three years ago
I watched my team — and every other .NET team I knew —
burn most of their hours not on business logic but on
plumbing the same four layers over and over:

EF Core + migrations. DbContext, fluent mappings, navigation properties, N+1 puzzles, lazy/eager loading, a migration per field, separate read/write models if you go CQRS. On a non-trivial object graph that's hundreds of hours just for the data layer, before any business logic is written.
A pile of integration connectors. Kafka here, RabbitMQ there, S3 for files, SFTP for the legacy partner, an HTTP webhook for the new one, each one hand-rolled with its own retry policy, dead-letter, idempotency, serialization, health check, telemetry. Ten integrations × 40-80 hours each.
Auth. OAuth flows, refresh tokens, scope checking, claims transformation, multi-tenant, M2M, DPoP if you want to be modern — built from IdentityServer / Auth0 / Keycloak plus 200-600 hours of glue per serious deployment.
Runtime. Hot-reload without dropping in-flight messages, graceful drain on redeploy, cluster coordination, leader election, watchdog, dashboard — usually missing entirely on .NET, or assembled from 5-7 unrelated NuGets that don't share conventions.

The worst part isn't any single layer — it's the seams
between them. Where the auth user becomes the EF entity
becomes the Kafka message becomes the S3 blob, every seam
is one more serialization, one more mapping, one more
versioning headache, one more place a 3 AM page comes from.

RedBase is built so that business code is the only thing
left to write. The class IS the schema (no EF, no
migrations). The 22 transports share one DSL (no per-connector
plumbing). Identity is a direct-vm:// Route (calling auth
is calling a function, not a network round-trip). Tsak gives
you hot-reload, cluster, dashboard, drain out of the box. The
seams collapse because everything lives on the same fabric.

On the one full business workflow where I had honest before/after
numbers — built the traditional way vs built on the RedBase
stack — the human effort was roughly ~3,000 hours vs ~128
hours. That ratio isn't magic on any single layer (where
each subsystem gives 3-5× at most); it comes from the seams
no longer existing. When I asked Claude Opus 4.7 to
sanity-check that estimate against typical .NET project
breakdowns (data layer + integrations + auth + runtime +
inter-seam testing), the order of magnitude held up.

One stack, one team, one architectural style — so the team
gets to write features instead of wiring infrastructure.
That is the project. Everything below is just how I got
there.

What I Built

RedBase — a four-pillar open-source ecosystem for .NET
that grew up inside one production system over three years
and finally got shipped to the world this spring. Three
pillars are now public on GitHub under Apache 2.0, and the
fourth is in pre-release polish:

1. redb — typed
object storage engine. Your C# class IS the schema. Two
physical tables (_objects + _values), full LINQ, zero
migrations, recursive-CTE tree queries, bulk COPY BINARY
saves on PostgreSQL and SqlBulkCopy on SQL Server. Free
core + Pro tier with tree-diff ChangeTracking saves.

2. redb-route
— Apache Camel for .NET. Fluent C# DSL for
From → Process → To pipelines, 22 transport packages
(Kafka, RabbitMQ, MQTT, S3, gRPC, SFTP, AMQP, Azure
Service Bus, IBM MQ, Elasticsearch, Redis, LDAP, FTP, HTTP,
WebSocket, SignalR, Firebase, TCP, Mail, SQL, Quartz,
generic File), 80+ EIP patterns (Splitter, Aggregator,
CBR, Circuit Breaker, Saga, ...), compiled expression
engine, transactional routes, OpenTelemetry built-in.

3. redb-tsak
— the .NET analogue of Apache Karaf / Camel K. Production
runtime container: drop a .tpkg bundle (ZIP with
manifest.json + entry-point DLLs + dependency DLLs +
per-module JSON config) — or just a bare .dll for the
simplest cases — into Libs/, get hot-reload without
dropping in-flight messages, REST + Blazor dashboard,
watchdog, Quartz scheduler, three deployment modes
(Standalone / Single-node+redb / Cluster with leader
election & auto-rebalance), per-module
AssemblyLoadContext isolation, API Key + HMAC-SHA256
security, 30-command CLI, typed C# client. 415+ tests.

4. redb.Identity (pre-release, repo opening soon) —
OAuth 2.1 / OIDC server, architecturally transport-agnostic:
every endpoint is a direct-vm:// Route. That gives two
ready usage modes today: (a) in-process — call the
auth server directly from another module in the same
run-time with zero network hop, zero serialization, zero
HTTP stack (this is what direct-vm:// is), and
(b) HTTP — a full OAuth 2.1 / OIDC HTTP facade is
shipped and working. The other RPC-capable facades —
gRPC, RabbitMQ RPC, AMQP request/reply, IBM MQ
request/reply, WebSocket, SignalR, TCP — are on the
roadmap and become near-trivial to add because the core
logic is already wire-format independent. (The
fire-and-forget transports in the Route set — Kafka
producer, File, S3, Mail, etc. — don't fit an auth
server, so they're correctly out of scope.) OpenIddict
under the hood, REDB-backed storage, DPoP / PAR / Dynamic
Client Registration / SCIM 2.0 / FIDO2 / WebAuthn /
RFC 8417 shared-signals support.
1751+ tests passing before public release.

Total scope: ~385k LOC (326k C# + 58k SQL) across
~2200 source files, Apache 2.0, NuGet-published, all
docs at redbase.app/why-redbase.

Demo

Live docs and positioning:

redbase.app/why-redbase — full "Sound familiar?" pain-point walkthrough with side-by-side Traditional-vs-RedBase code examples
The docs site itself is powered by RedBase — every page, example, and API reference is a REDB object in MSSQL. We eat our own cooking.

Published article series on dev.to
(author page) —
the ecosystem is too large for one post, so I'm publishing
a deep-dive series, one pillar at a time:

May 13 — We built an enterprise integration stack for .NET from scratch: EAV + DSL + runtime — overview of the whole stack
May 14 — I spent a year building Apache Camel for .NET. Here's the honest state of it. — discussion piece, what's done / what isn't
May 17 — redb.Route — Apache Camel for .NET: 22 transports, 30+ EIP patterns, compiled DSL — integration framework deep dive
May 21 — An EF Core alternative for .NET apps with complex object graphs — full LINQ, no migrations, no DbContext — REDB storage engine deep dive (this is the one that already triggered the multi-version-deploy thread referenced below)

…and the series continues. Tsak (runtime container,
hot-reload, cluster, watchdog) gets its own post next,
then Identity (transport-agnostic OAuth 2.1 / OIDC) when
the repo opens, then a deep dive on the tree-diff
ChangeTracking path, then a multi-DB benchmark post.
A stack this size is a genuinely hard engineering
problem to explain — trying to cram it into one article
would lie about the depth. So I'm taking it one layer
at a time.

The 30-second flavor:

// 1. Define schema — no migration needed
[RedbScheme("order")]
public class OrderProps
{
    public Customer Customer { get; set; }
    public Address ShippingAddress { get; set; }
    public List<OrderLineProps> Lines { get; set; } = [];
    public Dictionary<string, RedbObject<CouponProps>> Coupons { get; set; }
}

// 2. Save entire object graph in one call
await redb.SaveAsync(order);

// 3. Query with full LINQ over nested props
var hot = await redb.Query<OrderProps>()
    .Where(o => o.Customer.Address.City == "London"
             && o.Lines.Any(l => l.Qty > 10))
    .OrderByDescending(o => o.DateModify)
    .Take(50)
    .ToListAsync();

// 4. Tree query with recursive CTE under the hood
var allProducts = await redb
    .TreeQuery<Product>(londonHQ.Id, maxDepth: 10)
    .Where(p => p.InStock)
    .ToListAsync();

// Same dev defines a routing context with redb.Route.
// Real production patterns: REDB isn't a transport URI —
// it's accessed inside processors via DI (.ProcessWithRedb).
public class OrdersRouteBuilder : RouteBuilderBase
{
    public override void Build()
    {
        From("kafka://orders-raw")
            .Unmarshal<OrderProps>()
            .Split(o => o.Lines, EipParallel.Yes)
            .ProcessWithRedb(async (redb, exchange, ct) =>
            {
                var line = (OrderLineProps)exchange.In.Body;
                await redb.SaveAsync(line);   // REDB store
            })
            .Aggregate(by: e => e.In.Headers["OrderId"],
                       timeout: 5.Seconds())
            .To("rabbitmq://orders-enriched");

        // Staged queue with backpressure — exactly how the
        // production garage-sync route does it:
        From("seda://orders?concurrentConsumers=4")
            .ProcessWithRedb(EnrichFromInventoryAsync)
            .To("http://partner-api/orders");
    }
}

// Pack as a .tpkg bundle (manifest.json + entry-point DLL
// + dependency DLLs + module config.json) — or for trivial
// modules, just drop the bare .dll — into Libs/ of a Tsak
// node. Tsak picks it up, runs it across the cluster,
// rebalances on node failure, drains old versions on hot
// redeploy.
//
// Need the same flow gated by an OAuth scope?
// Two ready modes today:
//   * in-process — the call goes through direct-vm://
//     straight into redb.Identity, no network, no HTTP;
//   * over HTTP — standard OAuth 2.1 / OIDC endpoints.
// Tomorrow, the same auth server can also be exposed over
// any other RPC-capable Route transport (gRPC, RabbitMQ
// RPC, AMQP request/reply, IBM MQ, WebSocket, SignalR,
// TCP, ...) as those facades land — no change to the
// auth server itself:
//
//     .Process(ctx => ctx.RequireScope("orders.write"))

That last paragraph — "drops a .tpkg (or just a .dll),
gets hot-reload + cluster + dashboard + REST API + drain on
redeploy + an auth server callable from the same routing
fabric" — is the part I'm proudest of, because it's exactly
the piece
that's been missing from the .NET integration story for a
decade. Java had Karaf, Camel K, and a mature OIDC story
glued together. .NET had nothing equivalent that wasn't
either vendor-locked or hand-rolled per project.

The Comeback Story

Before (early 2026): all four pillars existed and
worked. Years of work. Real production load — 3-node
cluster, ~550 internal users at a HoReCa distributor,
~500k business objects, ~15M _values rows, three months
running every operational integration in the company.
And yet:

0 public repos. Everything in a closed monorepo.
0 NuGet packages. Even our own internal services built it from source.
0 published docs. A 14-line README.md in each project. "TODO: document this properly" in two of them.
0 external users. Nobody outside the company even knew it existed.
0 stars, 0 issues, 0 community. The classic "we'll open-source it when it's ready" trap — except it had been "ready enough for production" for over a year and "ready to share" still felt one polish-pass away every quarter.

The honest version: I was scared. ~385k LOC of opinionated
architecture decisions, exposed to public criticism, with
my real name on it. Easier to keep shipping it inside a
contract than to put it on the internet.

After (May 2026):

3 public GitHub repos under github.com/redbase-app: redb, redb-route, redb-tsak. Apache 2.0. CI, badges, real READMEs. The fourth (redb-identity) is in final polish — 1751+ tests green, repo opens before the contest deadline.
43 NuGet packages published (redb.Core, redb.Postgres, redb.Route.Kafka, redb.Tsak.CLI, ...) with ~18k cumulative downloads, the bulk of that (~15k) added in the active-launch window over the last ~10 days, on a clean upward curve day over day. External developers can dotnet add package today. Early signal: redb.Route (the integration framework) has already overtaken redb.Core in download count — 1497 vs 1482 — meaning the "Apache Camel for .NET" positioning is landing, not just the storage story. Inside Route, redb.Route.Http is the fastest-growing transport — confirming the hypothesis that HTTP is the natural first entry-point for new users exploring the DSL.
Marketing/docs site live at redbase.app — quick start, architecture page, pricing, full API docs. The site itself runs on REDB to prove the engine handles real content load.
A 4-post dev.to series already out (May 13 → May 21), with more deep dives queued. The REDB-storage post is already getting sharp technical questions in comments — including one about multi-version rolling deploys that surfaced a genuinely unsafe default in SyncStructuresFromTypeAsync (strictDeleteExtra = true) that I'd never noticed in three years of production use because we always single-version-deploy in our internal workflow. That defect went straight onto the fix list — exactly the kind of feedback that justifies open-sourcing in the first place.
First reactions and shares from the broader .NET community. Validation that the niche is real.

The completion arc isn't "I wrote a thing." The arc is
"I had a thing that worked for years inside one company
and I finally let it leave the building." Different muscle
entirely. Documentation, positioning, choosing what to call
it (RedBase / REDB / redb — we picked one and renamed
everything), writing READMEs for repos that had no audience
for years, recording first impressions, drafting tweets,
answering the first technical comment in public.

That last one is the hardest part of shipping. The code
was done. Letting it be judged was the work.

My Experience with GitHub Copilot

Honest framing first: a large part of this codebase is my
own work, written before Copilot was a serious factor.
The architectural decisions, the storage model, the
two-table layout, the tree-diff save strategy, the
direct-vm:// transport-agnostic routing fabric that lets
redb.Identity be called in-process today with zero
network hop and exposed over HTTP today and grow
additional facades over the RPC-capable Route transports
(gRPC, RabbitMQ RPC, AMQP, IBM MQ, WebSocket, SignalR,
TCP, ...) tomorrow — all without touching the auth server
itself — all of that came from years of sitting, thinking,
prototyping, and throwing prototypes away. No AI invented
those.

What Copilot changed was the finishing arc. The codebase
had the right shape, but it also had:

features sketched-in but not closed out;
helper layers half-typed because "I'll do this properly later";
XML doc-comments missing on 80% of public surfaces;
READMEs with TODO: document this;
corner cases I knew existed and had been deferring;
six different naming conventions across four years of rewrites that nobody had unified.

Copilot is what let me finally close all of that out
without burning a year of evenings.

Where it was a real force multiplier:

Finishing deferred features. Pieces I had on a
mental backlog for months — round-trip serialization
edge cases, missing operators on the LINQ provider,
Tsak CLI commands I'd been meaning to add, missing
transport options in redb.Route — Copilot let me
knock them out in evenings instead of weekends because
it could read the surrounding code, infer the
convention, and propose an implementation that I then
reviewed and corrected. The decisions stayed mine.
The typing speed and the "what was I about to do here"
recovery time collapsed.
Structuring code I already had. A lot of the work
wasn't writing new logic — it was taking working but
messy code, splitting it into the right files,
extracting the right interfaces, renaming things
consistently across ~2200 files. Copilot is excellent
at that kind of mechanical-but-context-sensitive
refactor where you need to keep semantics intact while
moving things around.
Comments and XML documentation at scale. Adding
/// <summary> to thousands of public members with
accurate descriptions of what each method actually
does — by hand this is a multi-week slog and you'll
give up after two days. With Copilot reading the
implementation and proposing the comment, then me
correcting where it was wrong, it became a steady
background task that actually finished.
Documentation and READMEs. ~12 projects, each
needing a consistent voice, accurate API examples,
correct cross-references, and a quick-start that
actually runs. With Copilot it became "draft → review
→ correct → ship" instead of "stare at empty file →
procrastinate." Same for the redbase.app positioning
pages — the "Sound familiar? / WITH REDBASE" pattern
you see on the site got drafted in one afternoon and
then iterated.
Cross-file architectural navigation while debugging.
The redb.Core.Pro ChangeTracking save path crosses
ValueTreeBuilder, ValueTreeDiff,
ProObjectStorageProviderBase, and the SQL bulk-ops
layer. Holding all four files in working memory
simultaneously while chasing a deduplication bug in
array hash updates — Copilot did the "where is this
called from, what's the contract" lookup, my brain did
the fix.
Honest fact-checking before publishing. I once
asked it to draft a reply claiming "old readers ignore
unknown structures gracefully on multi-version deploys."
It pushed back, we read the actual code together, and
the answer turned out to be "reads are graceful, writes
are destructive, and the production playbook
compensates with runtime drain." That nuance got
published. The first version would have been a small
lie. Same loop surfaced the strictDeleteExtra = true
default that's been on the fix list ever since.
RFC-driven implementation (this one mattered a lot
for Identity). redb.Identity is built almost
entirely on top of public RFCs: OAuth 2.1 / 6749,
Token Revocation 7009, Introspection 7662, Dynamic
Client Registration 7591 / 7592, JWK Thumbprint 7638,
SCIM 7644, OAuth for Native Apps 8252, Device
Authorization 8628, Token Exchange 8693, DPoP 9449,
Shared Signals 8417 — and that's not the full list.
For a solo developer, staying strictly compliant with
that many specs is brutal: every endpoint has
"MUST / SHOULD / MAY" clauses scattered across multiple
§-sections of multiple documents, edge cases like
"what status code on revoke of unknown token" (7009
§2.1: still 200), "must DPoP-Nonce rotate on every
bearing response" (9449 §8: yes), "is dpop_jkt binding
enforced at the token endpoint" (9449 §10.1: yes) \u2014
miss one and you've shipped a non-compliant auth
server. Copilot was constantly the "wait, RFC 7591 §3.2.1
says the response MUST include a registration access
token, did you cover that?" voice in the room. The
test suite reflects that: 1751+ tests with explicit
"RFC XXXX §Y.Z: ..." assertion messages, written
in the loop of "I remember the spirit of this clause,
Copilot, pull up the exact wording and let's make a
test out of it." Without that, achieving real RFC
compliance solo would have been a multi-year sub-project
on its own.

The pattern that emerged: I came in with the design
and most of the code already in place. Copilot saw what
was there, understood the conventions, and helped me
finish. Polish XML docs. Close out deferred TODOs.
Write the documentation pages. Refactor the inconsistent
bits. Catch the contradictions before they hit a public
comment thread. That's a different relationship than
"AI wrote my project." It's closer to having a very
fast pair-programmer who actually read the codebase
before sitting down.

Honest summary: ~385k LOC of infrastructure in three
years of part-time work was the human heroic effort.
Finishing it — closing out the deferred features,
filling in all the missing comments and documentation,
unifying the naming, writing the READMEs, shipping the
NuGet packages, drafting the dev.to articles, answering
the first hard comment in public — that's where Copilot
collapsed months into weeks. The contest prompt is
"revive and finish a project you started but never
completed." My project wasn't unfinished in design.
It was unfinished in all the small, deferred, boring,
necessary things that turn a working codebase into a
shippable product. Copilot is what made that finishing
arc actually fit inside one spring.

What's next (already in flight, not on a wish-list)

Shipping the four pillars wasn't the finish line — it was
the beginning of the public phase. Three big bets are
already underway, in source, in this repo:

Free engine is overtaking Pro. The
docs/FreePvtQuery
initiative is rewriting the REDB query path on top of
PostgreSQL PVT functions, and the free tier is already
ahead of Pro on a long list of features:
$case / $coalesce / $cast / n-ary $concat in
projections, full regex predicates ($regex,
$iregex, $regexReplace), extended math
($power, $sqrt, $log, $sin/cos/tan, ...),
extended string ops ($substring, $replace,
$indexOf, $padLeft/Right), projection-level
DISTINCT ON, date-extract in Select, and as of
2026-05-23 — HAVING for both regular and array
GroupBy (33/33 integration tests green across PG
Free + PG Pro + MSSql Pro). Net effect: most of what
used to be Pro-only is becoming free, and the
free engine is gaining capabilities Pro doesn't have
at all.
REDB outside C#. The whole point of building the
query layer as language-neutral JSON AST evaluated by
database-side PVT functions is that the C# LINQ
provider is just one front-end. The same _objects +
_values storage, the same scheme registry, the same
query AST can be driven from Python, from Google Apps
Script, from any language that can speak Postgres or
MSSQL — without porting the engine. That unlocks REDB
as a shared object store across heterogeneous stacks,
not just .NET shops. Architecturally, the work is
already done: every query goes through JSON AST →
PVT functions, no C#-side filter compilation required
for the heavy path.
Route keeps growing. New transport connectors are
on the roadmap, deep-dive articles for the Tsak
runtime container and for redb.Identity are queued
up after the contest deadline, and the EIP catalogue
is being expanded incrementally on top of the
existing 80+ patterns. The fastest-growing transport
(redb.Route.Http) is also driving a focused docs
pass on the HTTP path specifically.

The honest version: the ecosystem has been moving for
years and barely anyone outside one production deployment
knew. The potential is genuinely large — language-neutral
object storage with a full EIP runtime and a compliant
identity server on top of the same fabric is not a thing
that currently exists on .NET. That's the bet I'm
finishing.

Team: solo submission. All commits, all docs, all
articles by one author with Copilot in the loop.

Live in production: 3-node cluster, ~550 internal
users, ~500k objects, ~15M _values rows, ~2500 hours
uptime, zero data-layer incidents in 3 months.

Stack: .NET 8 / 9, PostgreSQL 17, MS SQL 2022,
Blazor Server, Quartz.NET, Npgsql, OpenIddict,
OpenTelemetry.

License: Apache 2.0 across all four pillars.

An EF Core alternative for .NET apps with complex object graphs — full LINQ, no migrations, no DbContext

rinat kozin — Thu, 21 May 2026 17:36:11 +0000

Today I'd like to slow down a bit and talk about redb.Core — the data engine at the heart of the RedBase ecosystem. The other pieces (redb.Route for pipelines, redb.Tsak for cluster runtime) lean on it, but this post is just about the database part.

I've been working on this project for several years. It started as an attempt to get rid of migrations and turned into what it is now — a typed object store for .NET over PostgreSQL and MSSQL.

It's not a weekend prototype. The free packages on NuGet are at version 2.0, there are 43 packages across the ecosystem, the architecture went through three rewrites, and as of this week it's been running 3 months on production at a 30-year national food distributor (more on that below).

This post is a technical walkthrough of redb.Core — what it is, how it differs from EF Core, what the generated SQL actually looks like, what the production workload looks like, and what's shipping next.

What redb.Core actually is

github.com/redbase-app/redb — Apache 2.0

RedBase stores typed C# objects in two tables (_objects + _values) over PostgreSQL or Microsoft SQL Server. Not JSON blobs. Not JSONB. Real typed columns with FK constraints — NUMERIC(38,18) for money, timestamptz for dates, uuid for GUIDs. Real B-tree indexes. ACID transactions.

The schema is your C# class:

[RedbScheme("Employee")]
public class EmployeeProps
{
    public string FirstName   { get; set; } = "";
    public string LastName    { get; set; } = "";
    public int    Age         { get; set; }
    public decimal Salary     { get; set; }
    public DateTime HireDate  { get; set; }
    public string[]? Skills   { get; set; }
    public Address? HomeAddress { get; set; }
    public Dictionary<int, decimal>? BonusByYear { get; set; }
}

That attribute is the entire schema definition. Call SyncSchemeAsync<EmployeeProps>() once — done. Add a property next sprint — redeploy, call sync again. Old objects still work. No migration files. No DBA ticket. No 2am rollback story.

// Save — entire object graph, one call
await redb.SaveAsync(employee);

// Load — full graph, arrays, dicts, nested classes — all materialized
var e = await redb.LoadAsync<EmployeeProps>(id);

// Query — real LINQ, real SQL
var seniors = await redb.Query<EmployeeProps>()
    .Where(e => e.Salary > 100_000 && e.Age >= 35)
    .OrderByDescending(e => e.Salary)
    .Take(50)
    .ToListAsync();

No DbContext. No Include chains. No Add-Migration. No mapper layer.

Object graphs in one call

This is the part that surprises people coming from EF. Props can contain other Props — single references, arrays, dictionaries — and the entire graph saves and loads as one operation:

[RedbScheme("Order")]
public class OrderProps
{
    public Customer Customer { get; set; }                          // nested class
    public Address ShippingAddress { get; set; }                    // nested class
    public Product[] Products { get; set; }                         // array of classes
    public RedbObject<PaymentProps>[] Payments { get; set; }        // array of full objects with own IDs
    public Dictionary<string, RedbObject<CouponProps>> Coupons { get; set; }  // dict of objects
    public Dictionary<(int Year, string Quarter), string> Reviews { get; set; } // tuple-key dict
}

await redb.SaveAsync(order);   // entire graph persisted, FK ordering handled
var loaded = await redb.LoadAsync<OrderProps>(id);
// loaded.Props.Customer.Address — ready
// loaded.Props.Payments[0].Props — ready (full RedbObject with own Id, DateCreate, etc.)
// loaded.Props.Coupons["SUMMER20"].Props — ready

In EF Core this would be 28 tables, ~40 Include/ThenInclude calls, manual junction tables for the many-to-many, and INSERT ordering that breaks every time someone adds a non-nullable FK without a default.

In RedBase: one SaveAsync, one LoadAsync. The nested RedbObject instances are real first-class objects — they have their own IDs, their own timestamps, they can be queried independently, they participate in tree structures. They are not denormalised JSON glued to the parent.

What the LINQ actually compiles to

Where(e => e.Salary > 100_000 && e.Age >= 35) doesn't get serialized to JSON and re-parsed (that's the Free engine's path — covered later). In Pro, the C# expression tree is walked node-by-node and emitted as parameterized SQL. Roughly:

WITH pvt AS (
  SELECT v._id_object,
         (array_agg(v._Numeric) FILTER (WHERE v._id_structure = $1))[1] AS "Salary",
         (array_agg(v._Long)    FILTER (WHERE v._id_structure = $2))[1] AS "Age"
    FROM _values v
   WHERE v._id_structure = ANY($3::bigint[])
     AND v._id_object IN (SELECT o._id FROM _objects o WHERE o._id_scheme = $4)
   GROUP BY v._id_object
)
SELECT o.*
  FROM _objects o
  JOIN pvt ON pvt._id_object = o._id
 WHERE pvt."Salary" > $5
   AND pvt."Age"    >= $6
 ORDER BY pvt."Salary" DESC
 LIMIT 50;

Parameterized. Plan-cached by PostgreSQL. One index scan on (_id_structure, _id_object), one aggregation pass, B-tree filter on flat columns. The number of filter fields doesn't change the shape of the query.

The C# → SQL compiler handles arithmetic (*, +, %), Math.*, String.Contains/StartsWith/Trim/ToLower, DateTime.Year/Month/..., nullable navigation (x.Address?.City) compiled to IS NOT NULL, the ternary operator compiled to CASE WHEN, StringComparison.OrdinalIgnoreCase compiled to native ILIKE, dictionary access dict["key"] compiled to pivot columns, and a few more edge cases that EF Core itself doesn't always handle.

You can preview the SQL of any query without executing it:

var sql = await query.ToSqlStringAsync();

Like IQueryable.ToQueryString() in EF, but works for trees, GroupBy, window functions too.

Why bulk save is so fast — two tables, two streams

Something to understand before the change-tracking section: the storage layout is two tables, so SaveAsync of a batch is two bulk operations, not N round-trips.

On PostgreSQL the provider uses Npgsql's BeginBinaryImportAsync — native COPY protocol, binary format:

// from redb.Postgres/Data/NpgsqlBulkOperations.cs
await using var writer = await conn.BeginBinaryImportAsync(
    "COPY _objects (_id, _id_parent, _id_scheme, _name, ...) FROM STDIN (FORMAT BINARY)");
foreach (var obj in objectsList) {
    await writer.StartRowAsync();
    await writer.WriteAsync(obj.Id,        NpgsqlDbType.Bigint);
    await writer.WriteAsync(obj.IdScheme,  NpgsqlDbType.Bigint);
    // ... typed writes
}
await writer.CompleteAsync();

For a batch save: one COPY stream writes the _objects rows, another writes the _values rows. Two streams, no per-row round-trips, no string-formatted INSERTs. MSSQL uses SqlBulkCopy for the same role.

This is why 1000 routes × ~40 fields = ~40,000 value rows save in tens of milliseconds inside the 200–300 ms budget. The bottleneck is the network round-trip and the COPY write, not the ORM machinery — there isn't any ORM machinery in the hot path.

Change tracking without DbContext (Pro)

DbContext keeps an in-memory snapshot of every entity you load — that's how it knows what changed. It's also why it isn't thread-safe and why the cache dies with the request.

RedBase Pro takes a different approach. With PropsSaveStrategy.ChangeTracking (Pro only; the free tier uses DeleteInsert), SaveAsync does this on a batch:

One bulk SELECT of existing values for all object IDs being saved.
Build two ValueTreeNode trees — one from your in-memory objects, one from the DB state.
Structural diff — subtrees with matching hashes are skipped entirely (no value comparison, no child traversal). Inserts, updates, and deletes are computed per node.
Three bulk operations — BulkInsertValuesAsync, BulkUpdateValuesAsync, BulkDeleteValuesAsync — each a single round-trip. Inserts go through COPY BINARY again.

Net effect: changing one field in a deeply nested object emits one UPDATE, not a full delete-and-reinsert of the entire props graph. And the comparison happens in C# on the application side — no DbContext lifetime to worry about, safe to run from a background Channel consumer or a Parallel.ForEach.

(In the production code from the previous section, the application also does its own obj.ComputeHash() check at the route level. That part is optional business-code — you could call SaveAsync on every route and the Pro tree-diff would still skip unchanged values internally. It's there as a coarse pre-filter so unchanged routes don't even enter the save pipeline at all, saving the diff work too.)

Production deployment — the numbers

The biggest deployment right now:

30-year national HoReCa food distributor
~150,000 orders/month, ~20,000 B2B customers, 600+ cities
3-node cluster, 4 cores / 8 GB RAM / 50 GB SSD per node
~550 daily internal users (operators, drivers, supervisors, dispatch, back-office)
10–15% CPU under full load
Integrations: SAP, Kafka, RabbitMQ, GPS feeds, Mercury / EGAIS / government APIs

Three months in production, no data-layer incidents. Two projects in the company use it, the second one came after the first one proved stable.

Real workload, real timings

The hottest pipeline is the SAP monitoring sync. Every 60 seconds a SQL polling consumer calls a stored procedure on SAP S/4 (usp_TsUM_MonitoringReport_xml), gets ~1000 transportation orders back as XML, syncs reference dictionaries (drivers, vehicles, list items), bulk-loads existing routes from RedBase, hash-compares each one, and saves only the changed ones.

The whole loop fits in ~200–300 ms for ~1000 routes. The actual production code:

From("direct://tsum")
    .RouteId("tsum-processing")
    .ProcessWithRedb(async (redb, exchange, ct) =>
    {
        var orders = (List<TransportationOrder>)exchange.In.Body;

        var sw = Stopwatch.StartNew();

        // 1. Sync dictionaries (Drivers, Vehicles, ListItems) — only new/changed
        var dicts = await DictionarySyncService.SyncFromOrdersAsync(redb, orders, ct);
        if (dicts.DriversNew + dicts.DriversChanged + dicts.VehiclesNew
            + dicts.VehiclesChanged + dicts.ListItemsRelinked > 0)
            await RefDataCache.RefreshAsync(redb);
        var syncMs = sw.ElapsedMilliseconds;

        // 2. Bulk load existing routes by Code — one query, ~1000 codes
        var codes = orders.Select(o => o.Code).ToList();
        var existing = await redb.Query<TransportationRoute>()
            .WhereRedb(o => codes.Contains(o.ValueString!))
            .ToListAsync();
        var existingByCode = existing.ToDictionary(o => o.ValueString!, o => o);

        // 3. Merge: update if hash changed, insert if new, skip if unchanged
        var toSave = new List<IRedbObject>();
        var updatedCount = 0;
        var skippedCount = 0;
        foreach (var order in orders)
        {
            var routeProps = MapOrderToRouteProps(order, dicts);
            if (existingByCode.TryGetValue(order.Code, out var obj))
            {
                var hashBefore = obj.ComputeHash();
                EnrichRouteFromOrder(obj.Props!, routeProps);
                if (obj.ComputeHash() != hashBefore) { toSave.Add(obj); updatedCount++; }
                else skippedCount++;
            }
            else
            {
                toSave.Add(new RedbObject<TransportationRoute>
                {
                    name = $"Route {order.Code}",
                    value_string = order.Code,
                    Props = routeProps
                });
            }
        }

        // 4. One batched save — mixed inserts + updates
        if (toSave.Count > 0)
            await redb.SaveAsync(toSave);

        Logger.LogInformation(
            "[TSUM] orders={Orders} routes(+{Created} ~{Updated} ={Skipped}) " +
            "drivers(+{DN} ~{DC}) vehicles(+{VN} ~{VC}) " +
            "sync={Sync} query={Query} save={Save} total={Total}ms",
            orders.Count, toSave.Count - updatedCount, updatedCount, skippedCount,
            dicts.DriversNew, dicts.DriversChanged,
            dicts.VehiclesNew, dicts.VehiclesChanged,
            syncMs, queryMs, saveMs, sw.ElapsedMilliseconds);
    });

TransportationRoute has ~40 fields and 12 RedbListItem references (Driver, Vehicle, CarMark, ShippingPoint, BusinessType, PlaceTo, PlaceFrom, LoadingZone, TransportStatus, Risk, DeliveryStatus, LoadStatus) plus 2 object references to AD users. Every single one is a foreign key in the database. None of them require a JOIN at query time — the materializer handles it.

Smaller queries (point-lookup of a single route, dictionary fetch, REST endpoints for the UI) run in 50–100 ms including HTTP overhead.

What's actually in the database

After running this in production, the storage looks like this:

~1000 transportation routes/day, plus delivery points, transport snapshots, garage states, slice settings, slice snapshots, drivers, vehicles, yard places, AD user refs — about a dozen [RedbScheme] classes in active use
~500,000 objects in _objects (routes, points, snapshots, dictionary items)
~15,000,000 rows in _values (every typed property of every object)
All of that lives in 2 tables — _objects and _values — plus the system tables for schemes, structures, lists, users, permissions

15 million typed value rows. Two tables. No 30-table schema. No 200 migration files. The query times above are on this dataset.

If you tried to model the same domain in EF Core flat tables, you'd end up with roughly: Routes, RoutePoints, TransportSnapshots, GarageStates, SliceSettings, SliceSnapshots, Drivers, Vehicles, CarMarks, ShippingPoints, BusinessTypes, YardPlaces, LoadingZones, TransportStatuses, DeliveryStatuses, Risks, TripRisks, AdUsers — plus junction tables and audit tables for each. 30+ tables, dozens of migrations, and every schema change is a deploy event.

In RedBase the schema change is git push. The next InitializeAsync() call adds the new structure rows. Done.

What would EF Core look like here?

I asked myself the same question before starting. Let's count what EF would need:

TransportationRoute entity → 1 table
12 ListItem references → 12 lookup tables + 12 nullable FKs
2 AD user references → 2 more FKs
The 1000-route batch update → 1000 entities tracked in DbContext for change detection
Hash-based skip of unchanged objects → doesn't exist in EF out of the box; you write it manually
The same logic across multiple processes/routes → DbContext is per-request, the change-tracker cache dies at the end of every batch

The realistic EF flow looks like this:

// Load existing — needs Include for every lookup or you get N+1
var existing = await db.Routes
    .Include(r => r.Driver)
    .Include(r => r.Vehicle)
    .Include(r => r.CarMark)
    .Include(r => r.ShippingPoint)
    .Include(r => r.BusinessType)
    .Include(r => r.PlaceTo)
    .Include(r => r.PlaceFrom)
    .Include(r => r.LoadingZone)
    .Include(r => r.TransportStatus)
    .Include(r => r.Risk)
    .Include(r => r.DeliveryStatus)
    .Include(r => r.LoadStatus)
    .Include(r => r.RiskSetBy)
    .Include(r => r.KcResponsible)
    .Where(r => codes.Contains(r.Code))
    .ToListAsync();

// Map, mutate, SaveChanges — 1000 tracked entities, full diff snapshot in RAM
// SaveChanges fires N UPDATE statements (one per row) in a transaction
await db.SaveChangesAsync();

In practice on a workload like this:

The Include chain on 14 lookups produces a query that PostgreSQL/MSSQL can't always optimise cleanly (cartesian explosion risk; you split-query and pay multiple round trips).
SaveChanges on 1000 modified entities emits 1000 individual UPDATEs unless you reach for EFCore.BulkExtensions or similar third-party libraries. RedBase ships COPY BINARY for inserts and a batched UPDATE path for updates in the box.
The DbContext snapshot of 1000 tracked entities, each with 14 included lookups, is real memory pressure. AsNoTracking() is faster but you lose change detection — you have to re-implement it.
The 200–300 ms budget on a 4-core container is not realistic in this scenario without significant manual optimisation and probably a separate bulk-update path.

I'm not saying EF can't do it. I'm saying the equivalent EF implementation is more code, more moving parts, and significantly slower without third-party packages. RedBase ships a single SaveAsync(toSave) and a hash-based skip primitive in the box.

The hash comparison itself (obj.ComputeHash() != hashBefore) is application-level business code — it's optional; the Pro tree-diff inside SaveAsync would skip unchanged values anyway. But used like this it lets the application skip the ~95% of routes that didn't change between SAP polls before they even enter the save pipeline. Combined with COPY BINARY into two tables and the Pro tree-diff for the routes that do change, the whole loop fits the 200–300 ms budget. No equivalent set of built-in primitives exists in EF Core; you either snapshot manually, re-save everything, or pull in third-party bulk packages.

What EF Core does with complex objects (vs what RedBase does)

The E000 benchmark uses EmployeeProps — a realistic model with nested classes, arrays, dictionaries, and RedbObject references:

What classic ORM needs	RedBase
~28 tables	2 tables
FK ordering on every INSERT	Single `SaveAsync`
40+ `Include`/`ThenInclude` calls	`LoadAsync<T>(id)` — one line
Migration file for every new field	Add property, call `SyncSchemeAsync`, done
~5,000 INSERTs for 100 employees	1 `BulkInsert` via COPY protocol

For 100 complex employees: EF Core ≈ 4,000–6,000 INSERTs across 28 tables in FK order. RedBase: ~3,000 typed value rows, one COPY command.

And the test results are published — 525 automated tests across all editions and both databases. All green.

The query engine: free vs Pro

This is where it gets technically interesting.

Free edition compiles your LINQ lambda to a JSON facet format, then calls a plpgsql stored procedure that parses that JSON and generates SQL dynamically. For simple 1–2 field filters, PostgreSQL optimizes correlated EXISTS subqueries well. It works.

Pro edition walks the C# expression tree directly in C# (ExpressionToSqlCompiler), emits native parameterized SQL. Same plan every call — PostgreSQL can cache it. 3–10× faster on complex multi-field filters.

But here's what's happening right now: I'm porting the Pro PVT CTE query engine into the free tier. The plan is full parity on PVT — same CTE shape, same expression coverage, same projection capabilities. Free and Pro will speak the same query dialect.

The remaining differences between Free and Pro will be elsewhere:

Query plan caching. Pro builds parameterized SQL in C# (ExpressionToSqlCompiler) — same shape every call, PostgreSQL caches the plan once and reuses it. The free tier generates SQL inside plpgsql with literal values inlined (properly escaped to prevent injection), so each call can produce a slightly different plan. Same correctness, different plan-cache behavior.
Materialization. Pro has a parallel materializer (multiple values streams hydrated concurrently into the object graph). Free uses a simpler sequential path.
Save strategy. PropsSaveStrategy.ChangeTracking (tree-diff with hash-based subtree skip) is Pro-only. Free uses DeleteInsert — still bulk via COPY, but no per-field diff.

So Pro stays faster on hot paths and large object graphs, but the query language itself — what you can write in .Where, .Select, projections, grouping, having, FTS, regex — will be the same on both sides.

Show me the SQL it generates

Here's a real example — a projection query on EmployeeProps with 16 computed columns:
full names, salary calculations, date extractions, seniority classification via CASE, coalesce for nullable fields, explicit type cast. This is the free tier:

WITH _pvt_cte AS (
    SELECT
        v._id_object,
        (array_agg(v._Long)    FILTER (WHERE v._id_structure = 1000017))[1] AS "Age",
        (array_agg(v._Numeric) FILTER (WHERE v._id_structure = 1000020))[1] AS "Salary",
        (array_agg(v._DateTimeOffset) FILTER (WHERE v._id_structure = 1000018))[1] AS "HireDate",
        (array_agg(v._String)  FILTER (WHERE v._id_structure = 1000016))[1] AS "LastName",
        (array_agg(v._String)  FILTER (WHERE v._id_structure = 1000015))[1] AS "FirstName"
    FROM _values v
    WHERE v._id_structure = ANY(ARRAY[1000015,1000016,1000017,1000018,1000020]::bigint[])
      AND v._id_object IN (SELECT o._id FROM _objects o WHERE o._id_scheme = 1000014)
    GROUP BY v._id_object
)
SELECT
    o._id                                                          AS id,
    ("FirstName" || ' ' || "LastName")                            AS full_name,
    UPPER("FirstName")                                             AS upper_name,
    LENGTH("FirstName")                                            AS name_len,
    ("Salary" * 12)                                                AS yearly_x12,
    (("Salary" * 0.15) - ("Salary" * 0.013))                      AS bonus_after_tax,
    ("Salary" / ("Age" + 1))                                       AS avg_per_year,
    ("Age" % 10)                                                    AS age_mod10,
    ABS(("Age" - 35))                                              AS abs_diff,
    FLOOR(("Salary" / 2))                                          AS floor_half_salary,
    EXTRACT(YEAR  FROM "HireDate")                                 AS hire_year,
    EXTRACT(MONTH FROM "HireDate")                                 AS hire_month,
    EXTRACT(YEAR  FROM AGE("HireDate", '2026-05-20'))              AS tenure_years,
    CASE
        WHEN ("Age" >= 60) THEN 'senior'
        WHEN ("Age" >= 35) THEN 'mid'
        ELSE 'junior'
    END                                                            AS seniority,
    COALESCE("FirstName", '<unknown>')                             AS display_name,
    ("Age")::text                                                  AS age_as_text
FROM _pvt_cte
JOIN _objects o ON o._id = _pvt_cte._id_object
WHERE "Salary" > '0'::numeric
ORDER BY "Salary" DESC
LIMIT 3

One _values scan. One GROUP BY. Sixteen computed output columns. Standard SQL — no magic, fully readable in pgAdmin, fully EXPLAIN ANALYZE-able.

This query was generated by pvt_build_projection_sql() — a plpgsql function that is shipping in the next free release.

When this fits and when it doesn't

Honest take.

Fits well: business apps with collections, nested structures, hierarchies, dictionaries, or schemas that change often. Apps where a business analyst can ask "add a field" and you want to ship the same day. Anything where you'd otherwise end up with 28 tables for one logical entity.

Doesn't fit: flat reporting databases with two or three fixed tables. Use Dapper there — it's honest and fast.

The common pushback is: "EF Core is good enough for 80% of projects." We'd flip that around: RedBase fits 80% of typical business projects — anything with collections, nested structures, lookup tables, hierarchies, dictionaries, or a schema that evolves alongside the product. The 20% where it's overkill is the genuinely flat case: two or three fixed tables, pure reporting, no evolving model. Use Dapper there; it's honest and fast. For everything else — which is most business software — the EF migration tax is real and it compounds with every sprint.

Three more axes that usually get left out of that comparison:

Extensibility. Adding a field is a property in C# and one InitializeAsync() call — no migration script, no review, no deploy window. The same change in an EF stack is at minimum: model edit + Add-Migration + reviewed SQL + coordinated deploy. Multiply by every iteration in a year.
Floor skill level. With RedBase, a junior developer who knows C# can add entities, fields, queries, and relationships on day one — the schema is just a class, the query is just LINQ. With EF Core on a complex model, you need to understand N+1, cartesian explosion from Include chains, DbContext lifetime, migration conflicts on shared branches, and when to reach for AsNoTracking(). That knowledge takes months to build and years to apply consistently. RedBase moves that complexity into the framework and out of the application code.
Cost of development. On the TsUM project the data-layer work — schemas, storage, queries, sync pipelines, change-tracking, bulk save — came in at roughly 128 person-hours. The estimate for the same scope on a classic EF + handwritten bulk-update + ASP.NET Identity + 30-table migration stack was on the order of 3000 person-hours. That's not a typo and it's not marketing — it's the gap between "add a property, redeploy" and "add a column, write migration, update DTOs, update mapper, update repository, write tests for all of it". The 80%/20% framing only holds if you count lines of code; once you count engineer-hours over a project lifetime it inverts.

What else is in the box

195+ working examples in the repo. The shortlist of things people usually don't expect to be built-in:

// Tree queries — recursive CTE underneath, no CTE to write yourself
var products = await redb.TreeQuery<Product>(londonHQ.Id, maxDepth: 10)
    .Where(p => p.InStock)
    .ToListAsync();

// Soft delete with atomic mark + background purge + progress in DB
await redb.SoftDeleteAsync(ids, user);

Also shipping in the core (this is the short list — the real list is much longer):

GroupBy + window functions in one query
Built-in users / roles / permissions (no ASP.NET Identity dependency, no separate auth schema)
Export / import via .redb files (PostgreSQL ↔ MSSQL portability)
Multi-database in one process with full domain isolation — separate connections, separate scheme caches, separate object caches per domain; one app can talk to several independent RedBase databases at the same time without their metadata leaking into each other
Scheme cache and object cache (both per-domain), invalidated on SyncSchemeAsync / SaveAsync, used by the materializer to skip repeated metadata lookups
Atomic soft-delete with background purge and progress visible in the DB
Tree queries with recursive CTE
Polymorphic trees — different C# types at each level of the same tree

There's a lot more that doesn't fit in one section. The architecture page has the full map.

What's coming next

The FreePvtQuery release is the nearest milestone. This is a complete rewrite of the free tier's query engine based on the PVT CTE architecture — bringing it to full parity with Pro on the query side:

Single-pass _values scan (vs correlated EXISTS per field)
Full expression system: arithmetic, string, date, math, regex, FTS, CASE, coalesce, cast
Projections with arbitrary computed columns (like the SQL above)
HAVING, DISTINCT ON, GROUP BY extensions

After that: MSSQL support for the new engine, C# LINQ-to-JSON bridge so you keep writing .Where(e => e.Salary > 100_000) without touching JSON. Pro will keep its edge on plan caching (parameterized SQL), parallel materialization, and tree-diff change tracking.

This is maybe 10% of what's in there

This post covered the basics: storage model, query engine, free PVT demo, production deployment. Topics I didn't touch:

Polymorphic tree hierarchies (different C# types at every level, same tree API)
Object graphs with RedbObject<T> references inside Props
Data migrations (Pro): fluent API, computed columns, in-place type changes
Export/import: .redb files (JSONL/ZIP), PostgreSQL ↔ MSSQL portability
Multi-database in one process (domain-isolated caches)
redb.CLI — schema management from command line
redb.PropsEditor — runtime props editing UI
Integration with redb.Route (22-transport pipeline engine) — separate article

If there's a direction you want covered next — migrations, polymorphic trees, benchmarks, internals of the diff-tree change tracking — drop it in the comments and that's what the next post will be.

redb.Route — Apache Camel for .NET: 22 transports, 30+ EIP patterns, compiled DSL

rinat kozin — Sun, 17 May 2026 10:26:13 +0000

Apache Camel has been solving enterprise integration on the JVM since 2007 — 22k stars, 300+ transports, hundreds of production deployments at banks, telcos, governments. The .NET ecosystem never got a real equivalent. MassTransit and Wolverine cover message-bus and saga scenarios well, but they aren't pipeline engines and they don't pretend to be.

redb.Route is the missing piece: a fluent C# DSL that wires Kafka, RabbitMQ, Redis, SQL, HTTP, gRPC, SFTP, MQTT, S3 and 14 more transports through From → Process → To pipelines, with 30+ Enterprise Integration Patterns and a compiled expression engine. Apache 2.0, .NET 8 / 9 / 10. This post is a technical walkthrough.

The shape of every pipeline

Every redb.Route pipeline is From → [processors] → To. Messages flow as IExchange instances carrying a body, headers, and properties.

From("kafka://orders?groupId=svc&brokers=localhost:9092")
    .Filter(Header("type").isEqualTo("new"))
    .To("rabbitmq://events?host=localhost");

For complex routing, group routes into a RouteBuilder:

public class OrderRoutes : RouteBuilder
{
    protected override void Configure()
    {
        From("kafka://orders?groupId=svc&brokers=localhost:9092")
            .RouteId("order-pipeline")
            .Choice()
                .When(Header("priority").isEqualTo("high"))
                    .Log("High priority order")
                    .To("direct://fast-lane")
                .When(Header("priority").isEqualTo("low"))
                    .To("seda://batch-queue")
                .Otherwise()
                    .To("direct://standard")
            .EndChoice();

        From("direct://fast-lane")
            .Retry(3)
            .SetHeader("processed-at", e => DateTimeOffset.UtcNow)
            .Process(async (exchange, ct) =>
            {
                var body = exchange.In.Body as string;
                exchange.In.Body = $"PROCESSED: {body}";
            })
            .To("rabbitmq://processed?host=localhost");
    }
}

Registration:

builder.Services.AddRedbRoute(route => route.AddRouteBuilder<OrderRoutes>());
builder.Services.AddRedbRouteKafka();
builder.Services.AddRedbRouteRabbitMQ();

22 transports as first-class URI schemes

kafka://          rabbitmq://       redis://          sql://
http://           grpc://           sftp://           ftp://
mqtt://           s3://             ibmmq://          amqp://
azuresb://        elasticsearch://  firebase://       ldap://
mail://           tcp://            websocket://      signalr://
cron://           file://

+ built-in: direct://   seda://   timer://   log://   mock://

Every transport uses the same IExchange contract. Swapping Kafka for RabbitMQ means changing the From URI — the pipeline logic is unchanged.

Type-safe fluent builders are available as an alternative to URI strings:

var source = Kafka.Topic("orders")
                  .Brokers("broker1:9092,broker2:9092")
                  .GroupId("order-svc")
                  .Acks("All");

From(source).To("seda://internal");

EIP patterns as DSL steps

Content-Based Router — route by message content:

From("kafka://events")
    .Choice()
        .When(Header("type").isEqualTo("order"))   .To("direct://orders")
        .When(Header("type").isEqualTo("invoice"))  .To("direct://invoices")
        .Otherwise()                                .To("seda://unclassified")
    .EndChoice();

Splitter + Aggregator — split a batch, process each item, re-aggregate by correlation key. Sequential by default; one method turns the split into a bounded-parallel pipeline:

From("seda://batch")
    .Split(Body())                                     // Body() helper — split the IEnumerable body
        .ParallelProcessing()                          // process items concurrently
        .MaxDegreeOfParallelism(8)                     // bounded fan-out
        .Process(async (ex, ct) => await EnrichOrder(ex))
        .To("direct://enriched")
    .EndSplit();

From("direct://enriched")
    .Aggregate(Header("batch-id"), new ListAggregationStrategy())
    .To("rabbitmq://processed-batches");

For true fan-out to multiple endpoints in parallel use Multicast:

From("kafka://orders")
    .Multicast("direct://pricing", "direct://inventory", "direct://fraud-check");

WireTap — copy every message to an audit sink without interrupting the main flow:

From("kafka://transactions")
    .WireTap("direct://audit-log")
    .Process(async (ex, ct) => await ProcessTransaction(ex))
    .To("rabbitmq://completed");

Idempotent Consumer — deduplicate across a cluster. Plug in the repository (in-memory, SQL, or redb.Core EAV) and the same message ID is rejected on every node:

From("kafka://payments")
    .IdempotentConsumer(
        e => e.In.GetHeader<string>("payment-id"),
        new RedbIdempotentRepository(redbService))   // cluster-wide, two-phase commit
    .Process(async (ex, ct) => await ProcessPayment(ex));

Saga — pipeline-level choreography with compensating steps. If ChargePayment throws, ReleaseInventory runs automatically. No external state-machine framework required:

From("direct://checkout")
    .Saga(s => s
        .Step(
            action:     async (ex, ct) => await inventory.Reserve(ex, ct),
            compensate: async (ex, ct) => await inventory.Release(ex, ct))
        .Step(
            action:     async (ex, ct) => await payments.Charge(ex, ct),
            compensate: async (ex, ct) => await payments.Refund(ex, ct))
        .Step(
            action:     async (ex, ct) => await shipments.Create(ex, ct),
            compensate: async (ex, ct) => await shipments.Cancel(ex, ct))
        .OnCompletion(async (ex, ct) => await PublishOrderCompleted(ex, ct)))
    .To("rabbitmq://order-confirmed");

Full catalogue: Filter, Choice, Splitter, Aggregator, Multicast, WireTap, Recipient List, Dynamic Router, Resequencer, Scatter-Gather, Claim Check, Idempotent Consumer, Saga, Circuit Breaker, Throttle, Retry, Dead Letter, Loop, Delay, Debounce, Enrich, Timeout, TryCatch, Transacted, Process, Validate. 30+ patterns, all first-class DSL.

Error handling — four composable layers

Most .NET libraries give you one mechanism for failures: a retry policy on the consumer. redb.Route exposes four, designed to compose: per-step Retry, scoped DoTry/DoCatch, route-local OnException, and global OnException declared at the RouteBuilder level. Plus DeadLetterChannel for messages that exhaust retries.

Dead Letter Channel + a DLQ sub-route that knows why it failed

The failing exception travels with the exchange. The DLQ sub-route can read it, branch on the type, log structured info, archive, retry later:

From("kafka://orders")
    .DeadLetterChannel("seda://orders-dlq")
    .Retry(3)
    .Process(async (ex, ct) => await ProcessOrder(ex, ct))
    .To("rabbitmq://processed");

// The DLQ is a real route — inspect, branch, react
From("seda://orders-dlq")
    .Log("DLQ: ${header.correlationId} — ${exception.message}")
    .Choice()
        .When(e => e.GetException() is TimeoutException)
            .Delay(TimeSpan.FromMinutes(5))
            .To("seda://retry-later")
        .When(e => e.GetException() is HttpRequestException)
            .To("sftp://archive/http-failures/")
        .Otherwise()
            .To("sftp://archive/poison/")
    .EndChoice();

OnException — per-exception redelivery with exponential backoff

Declared globally at RouteBuilder level (applies to every route in the builder) or scoped to a single route. Each block configures attempts, delay, backoff, and what to do when the handler succeeds:

public class OrderRoutes : RouteBuilder
{
    protected override void Configure()
    {
        // Global — applies to every From(...) below
        OnException<HttpRequestException>()
            .MaximumRedeliveries(5)
            .RedeliveryDelay(TimeSpan.FromSeconds(1))
            .UseExponentialBackOff()
            .BackOffMultiplier(2.0)
            .Handled()                          // mark as handled — exchange continues normally
            .To("seda://http-failures")
        .EndOnException();

        OnException<DbException>()
            .MaximumRedeliveries(2)
            .UseOriginalMessage()               // restore original body before sending to handler
            .OnWhen(e => !((DbException)e.GetException()).Message.Contains("deadlock"))
            .To("seda://db-failures")
        .EndOnException();

        // Multiple exception types in one block
        OnException(typeof(TimeoutException), typeof(SocketException))
            .MaximumRedeliveries(3)
            .RedeliveryDelay(TimeSpan.FromSeconds(2))
            .To("seda://network-failures")
        .EndOnException();

        From("kafka://orders")
            .To("http://payments-svc/charge");

        From("kafka://shipments")
            .To("http://logistics-svc/dispatch");
    }
}

Handled(), Continued(), OnWhen(predicate), RetryWhile(predicate), UseOriginalMessage() — all standard Camel error-handling primitives, and none of the .NET alternatives ship them as DSL.

TryCatch — scoped try/catch/finally inside a pipeline

When only one section of a route needs special handling:

.DoTry()
    .To("http://external-api/submit")
    .Process(async (e, ct) => await PostProcess(e, ct))
.DoCatch<HttpRequestException>()
    .Log("HTTP failure: ${exception.message}")
    .To("seda://retry-queue")
.DoCatch<TimeoutException>()
    .To("sftp://archive/timeouts/")
.DoFinally()
    .Log("Attempt complete")
.End()

Compiled expression engine

This is the one feature that distinguishes redb.Route from both Apache Camel and every .NET alternative. Inline expressions — string templates, arithmetic, comparisons, JSONPath, XPath — are translated to real Func<IExchange, T> delegates via System.Linq.Expressions at route-build time. No interpreter, no per-message parsing.

// String templates
.SetBody(Expr("${header.orderId}-${body}"))
.SetHeader("trace", Expr("${header.source}-${header.correlationId}"))

// Pre/post-increment
.SetHeader("attempt", Expr("${header.attempt++}"))   // returns old value
.SetHeader("attempt", Expr("${++header.attempt}"))   // returns new value

// Arithmetic
.SetHeader("total", Expr("${header.qty * header.price}"))
.SetHeader("net",   Expr("${header.gross - header.tax}"))

// Predicates — fluent on top of compiled expressions
.Filter(Expr("header.amount").isGreaterThan(1000))
.When(Header("status").isEqualTo("active"))

Apache Camel's Simple Language is interpreted at every message dispatch. MassTransit, Wolverine and NServiceBus have no expression engine at all — every conditional is a hand-written C# lambda. With redb.Route you get both: terse string DSL for configuration-driven rules and strongly typed lambdas where you want them, with the same zero-overhead delegate at the bottom.

The engine supports 9 value types and 17 predicates, and the result of every Expr(...) is cached per route. You pay for parsing once at startup.

Transactional pipelines

A pipeline can wrap several steps in a single transaction. .Transacted() opens a TransactionScope; transports that implement ITransactedAction enlist into it. That means the Kafka commit, the RabbitMQ publisher confirm, and the SQL UPDATE all succeed or fail together — no half-processed messages, no manual two-phase coordination:

From(Kafka.Topic("orders")
        .Brokers("broker:9092")
        .GroupId("order-svc")
        .IsolationLevel("ReadCommitted")
        .EnableAutoCommit(false))                      // commit driven by .Transacted()
    .Transacted()
    .Process(async (ex, ct) => await Validate(ex, ct))
    .To(Sql.Execute("INSERT INTO orders (...) VALUES (...)")
           .DataSource("main")
           .Transacted())                              // enlists into the same scope
    .To(Rabbit.Queue("order-events")
              .Confirms(true));                        // publisher confirm before commit

MassTransit, NServiceBus and Wolverine all solve this for their own bus, but only for the bus. redb.Route makes it work across any combination of transports that implement ITransactedAction — Kafka EOS, RabbitMQ tx channels, IBM MQ, AMQP 1.0, SQL.

Outbox without an outbox framework

The transactional outbox pattern is usually presented as a feature you opt into via a framework (MassTransit, NServiceBus, Wolverine all bundle one). In redb.Route it's just four lines composed from existing primitives — SQL polling, transactional sink, idempotent consumer:

From(Sql.Poll("SELECT id, payload FROM outbox WHERE processed = 0 LIMIT 100")
        .DataSource("main")
        .OnSuccess("UPDATE outbox SET processed = 1 WHERE id = ANY(@ids)")
        .Transacted())                                  // atomic claim + publish
    .Split(Body())
    .IdempotentConsumer(
        e => e.In.GetHeader<string>("eventId"),
        new RedbIdempotentRepository(redbService))      // dedup on republish
    .To(Kafka.Topic("events")
             .EnableTransactionalProducer(true)
             .Acks("All"));                             // exactly-once on the broker

No magic table conventions, no separate IOutbox interface to register, no required ORM. It's pipelines all the way down.

Request-Response — HTTP and gRPC as first-class endpoints

The same DSL that handles fire-and-forget Kafka also handles synchronous RPC. Mark the listener InOut(), set In.Body to the response anywhere in the pipeline — the HTTP transport sends it back to the caller:

public class OrderApi : RouteBuilder
{
    protected override void Configure()
    {
        From(Http.Listen("/api/orders").Port(8080).InOut())
            .Unmarshal(typeof(JsonMessageSerializer), typeof(CreateOrderRequest))
            .Validate(e => (e.In.Body as CreateOrderRequest)?.Amount > 0,
                      "Amount must be positive")
            .Process(async (e, ct) =>
            {
                var req  = (CreateOrderRequest)e.In.Body!;
                var resp = await orderService.CreateAsync(req, ct);
                e.In.Body = resp;                      // HTTP transport returns In.Body to the caller
            })
            .WireTap("kafka://order-created")          // audit — fire-and-forget, non-blocking
            .Marshal(typeof(JsonMessageSerializer));
    }
}

Replace Http.Listen with Grpc.Listen or Ws.Listen — same pipeline. RPC, validation, business logic, audit, and serialization in one declarative route. No separate controller layer, no separate consumer layer.

Testing without a broker — `mock://`

The mock: transport records every message it receives so unit tests can assert against an in-memory endpoint. No Kafka container, no RabbitMQ container, no Testcontainers — a plain Host and a few lines of xUnit:

[Fact]
public async Task Filter_only_forwards_new_orders()
{
    var host = Host.CreateDefaultBuilder()
        .ConfigureServices(s => s.AddRedbRoute(route => route.AddRoutes(r =>
        {
            r.From("direct://input")
                .Filter(Header("type").isEqualTo("new"))
                .To("mock://received");
        })))
        .Build();
    await host.StartAsync();

    var producer = host.Services.GetRequiredService<IRouteProducer>();
    var mock     = host.Services.GetRequiredService<MockComponent>().GetEndpoint("received")!;

    await producer.SendAsync("direct://input", "payload-1",
        new Dictionary<string, object> { ["type"] = "new" });
    await producer.SendAsync("direct://input", "payload-2",
        new Dictionary<string, object> { ["type"] = "old" });

    Assert.Equal(1, mock.ReceivedCount);
    Assert.Equal("payload-1", mock.ReceivedExchanges[0].In.Body as string);
}

For async routes use MockDsl.Endpoint("name").ExpectedMessageCount(n) — it awaits the expected count with a timeout. This is the Camel testing idiom and one of the reasons unit tests on Camel routes are pleasant. .NET integration libraries usually leave you to Testcontainers.

Telemetry — OpenTelemetry built in, on by default

Every step in every route emits an Activity and a Meter sample. No AddInstrumentation, no per-step manual spans, no decorator wrapping. EnableTelemetry and EnableMetrics are true out of the box — point your collector at the process and you immediately see per-route traces and per-step latency.

For named sections that should show up as their own span or counter in Grafana / Jaeger / Tempo, the DSL has Traced and Metered:

From("kafka://orders")
    .Traced("order-processing")                   // one Activity for the whole block
        .SetBody(JPath("$.order"))
        .Process(async (e, ct) => await Enrich(e, ct))
    .EndTraced()
    .Metered("order-throughput")                  // counter + histogram for the block
        .To("rabbitmq://processed")
    .EndMetered();

// Inline form when the named span wraps a single step
From("kafka://orders")
    .Traced("validate", async (e, ct) => await ValidateOrder(e, ct))
    .Metered("transform", e => { e.In.Body = Transform(e); })
    .To("rabbitmq://processed");

Standard metric names: redb.route.messages.processed, redb.route.messages.failed, redb.route.processing.duration — emitted per route and per named step. They drop straight into any OTel-compatible backend.

What a real production route looks like

The examples above are deliberately short. Real routes nest: HTTP listener → auth → permission check → method dispatch → business handler → audit tap. Indentation is the route hierarchy. The whole shape of the request is visible top-down:

From  http://0.0.0.0:5090/api/.../settings   (inOut, cors)
  Process            Auth.ProcessAsync
  ConvertBody<string>
  Choice on Header redbHttp.Method
  ├─ POST
  │    RequirePermission   EditSettingsTables
  │    ProcessWithRedb     HandlePost
  │    WireTap → direct://audit   (onPrepare + newBodyFactory)
  ├─ DELETE
  │    RequirePermission   EditSettingsTables
  │    ProcessWithRedb     HandleDelete
  │    WireTap → direct://audit
  └─ else
       ProcessWithRedb     HandleGet
  EndChoice
Respond → HTTP caller

This is one route from the production system mentioned at the bottom of the post — settings API for a logistics admin panel:

protected override void Configure()
{
    From("http:0.0.0.0:5090/api/tsum/special-rc-settings?inOut=true&cors=true&corsOrigins=*")
        .RouteId("tsum-api-special-rc-settings")
        .Process(Auth.ProcessAsync)                       // attach IPrincipal to exchange
        .ConvertBody<string>()
        .Choice()
            .When(Header("redbHttp.Method").isEqualTo("POST"))
                .Process(TsumAuthProcessor.RequirePermission(TsumPermission.EditSettingsTables))
                .ProcessWithRedb((redb, ex, ct) => HandlePost(redb, ex))
                .WireTap("direct://tsum-audit",
                    onPrepare:      e => TsumAuditHelper.SetHeaders(e, "DATA_CHANGE"),
                    newBodyFactory: TsumAuditHelper.BuildDetailsJson)
            .When(Header("redbHttp.Method").isEqualTo("DELETE"))
                .Process(TsumAuthProcessor.RequirePermission(TsumPermission.EditSettingsTables))
                .ProcessWithRedb((redb, ex, ct) => HandleDelete(redb, ex))
                .WireTap("direct://tsum-audit",
                    onPrepare:      e => TsumAuditHelper.SetHeaders(e, "DATA_CHANGE"),
                    newBodyFactory: TsumAuditHelper.BuildDetailsJson)
            .Otherwise()
                .ProcessWithRedb((redb, ex, ct) => HandleGet(redb, ex))
        .EndChoice();
}

private async Task HandleGet(IRedbService redb, IExchange exchange)
{
    var shippingPointId = ParseQueryLong(exchange, "shippingPointId")
                       ?? ParseQueryLong(exchange, "rcId");
    if (!shippingPointId.HasValue)
    {
        BadRequest(exchange, "shippingPointId required");
        return;
    }

    var items = await redb.Query<SpecialRcSettings>()
        .Where(s => s.ShippingPoint == shippingPointId)
        .ToListAsync();

    JsonRouteHelper.SetJsonBody(exchange, items
        .Select(MapToDto)
        .OrderBy(x => x.CustomName)
        .ToList());
}

Two features worth pointing out:

ProcessWithRedb((redb, ex, ct) => ...) — typed access to a named redb.Core service inside the pipeline. redb.Query<SpecialRcSettings>().Where(...).ToListAsync() is just LINQ over a typed EAV scheme. No DbContext, no migrations, no separate repository class.
WireTap("direct://tsum-audit", onPrepare: ..., newBodyFactory: ...) — the audit hop runs in parallel with the main response, gets its own headers and its own body built fresh from the exchange. The HTTP client doesn't wait for audit, but audit sees the exact state of the exchange at that step.

This is the actual shape of a real route. Method dispatch, auth, permission, business handler, audit — in one declarative block that reads top-down.

How it compares

	Apache Camel	MassTransit	NServiceBus	Wolverine	redb.Route
Language	Java/JVM	C#	C#	C#	C#
Transports	300+	5	7	4	22
EIP patterns (DSL)	80+	~5	~5	~5	30+
Expression engine	Interpreted	—	—	—	Compiled
Transactional pipelines across transports	Yes	Bus only	Bus only	Bus only	Yes
Runtime container	Karaf / Camel K	Worker Service	Worker Service	Worker Service	redb.Tsak
License	Apache 2.0	Apache 2.0	Commercial (>2 endpoints)	MIT	Apache 2.0

MassTransit, NServiceBus and Wolverine solve a different problem — they are message-bus frameworks with handler discovery, durable sagas and managed outbox. redb.Route is a pipeline and transport integration engine. They are not mutually exclusive: use redb.Route for cross-protocol routing and transformation, MassTransit for handler-style messaging and long-running saga state.

Deploying to production — redb.Tsak

Writing RouteBuilder classes is one thing. Running them in production across multiple nodes is another.

redb.Tsak is the runtime container built for redb.Route:

Drop a .dll or .tpkg (ZIP + manifest) into Libs/ — Tsak loads it without restart
Hot-reload — update the file while running, zero downtime for other routes
Cluster mode — leader election, automatic context redistribution across nodes. No ZooKeeper, no etcd. Coordination uses row locks in redb.Core.
REST API (32 endpoints), CLI (30 commands), Blazor dashboard with per-route metrics, logs, watchdog, cluster view

You do not change a single line of RouteBuilder code to go from dotnet run to a 3-node production cluster.

Full writeup on Tsak is coming in the next article. For now: github.com/redbase-app/redb-tsak.

Current state

Running at EWS — a 30-year-old national HoReCa food distributor:

3-node cluster (4 cores / 8 GB / 50 GB SSD per node)
~150k orders/month, ~3 months stable, 10–15% CPU under full load
Active transports: SAP, Kafka, RabbitMQ, GPS feeds, Mercury / EGAIS / Chestny Znak / FGIS Grain

27 NuGet packages (core engine + 22 transports + 5 support libraries). Apache 2.0.

It's not Apache Camel — not in transport count, not in maturity, not in ecosystem. But for the kind of integration work most .NET teams actually ship, it covers the ground a single library reasonably can. Honest feedback, missing transports, and breaking-case bug reports are all welcome.

Links


redb.Route	github.com/redbase-app/redb-route
redb.Tsak	github.com/redbase-app/redb-tsak
Architecture	redbase.app/architecture
Discussions	github.com/redbase-app/redb-route/discussions

Over to you

This is exactly the moment when honest outside input is worth more than another internal sprint. A few specific things I'd love to hear:

Transports. 22 cover most stacks I've seen, but obvious gaps remain. NATS / NATS JetStream? Pulsar? Service Bus topics with sessions? Google Pub/Sub? SQS+SNS as a pair? Salesforce Streaming API? OPC UA? Tell me what would make redb.Route a real fit for your stack.
EIP patterns. 30+ ship today. Anything from the Hohpe/Woolf catalogue you'd actually use and can't easily get elsewhere in .NET? Message Store with replay? Routing Slip? Process Manager? Normalizer? Format Indicator?
DSL ergonomics. Anything in the examples above that reads awkwardly in C#? Where would [Source]/[Sink] attributes, source generators, minimal-API-style MapRoute("/orders"), or top-level statement DSL feel better than RouteBuilder classes?
Observability. OpenTelemetry is built in and on by default; Grafana dashboards and the live metrics / logs UI live in redb.Tsak (full writeup in the next article). What's still missing from your point of view — opinionated dashboard JSON, a turnkey OTel collector recipe, exemplars wired to trace IDs?
Migration. If you have an existing Apache Camel route in production, would a side-by-side translation walkthrough (Camel Java → redb.Route C#) be useful? Which patterns hurt most?
What stops you from trying it. "License is good, but…" / "I like the DSL, but…" — the but is the most valuable feedback I can get right now.

Drop a comment, open an issue, or start a thread in Discussions. Critical responses get the same priority as kind ones — both move the project forward.

I spent a year building Apache Camel for .NET. Here's the honest state of it.

rinat kozin — Fri, 15 May 2026 16:23:44 +0000

I've spent the last year building an integration ecosystem for .NET that I think fills a real gap. Three repos just went public. This post is the honest account — what it does, what it doesn't do yet, and three questions I genuinely don't know the answer to.

The gap

If you need Apache Camel in .NET, you don't have it.

MassTransit, Wolverine, NServiceBus are message buses — great at what they do, but they give you 4–7 transports and a Saga pattern. Apache Camel has 300+ components and 80+ EIP patterns as first-class DSL. But it's JVM.

There's no .NET project that gives you the full EIP catalogue —
Splitter, Aggregator, Content-Based Router, Recipient List, Dynamic Router,
Wiretap, Dead Letter Channel — as a fluent C# DSL with 20+ transports.

So I wrote one.

What I built

redb.Route — Camel-style fluent C# DSL. Apache 2.0.
github.com/redbase-app/redb-route

22 transports: Kafka, RabbitMQ, Redis, SQL polling, HTTP, gRPC, SFTP, MQTT,
S3, IBM MQ, AMQP 1.0, Azure Service Bus, Elasticsearch, LDAP, Mail, TCP,
WebSocket, SignalR, FTP, Quartz, File — plus 5 built-in (direct, seda, timer, log, mock).

30+ EIP processors as first-class DSL steps. Compiled expression engine:
${header.price} * 1.2 compiles to Func<IExchange, decimal> via
System.Linq.Expressions at route-build time. No interpreter at runtime.

redb.Tsak — runtime container for redb.Route modules. Apache 2.0.
github.com/redbase-app/redb-tsak

Drop a .dll or .tpkg (ZIP + manifest) into a folder. Tsak picks it up,
wires the DI container, starts the routes. Hot-reload — replace the file while
running, zero downtime. REST API + CLI + Blazor dashboard.

Cluster: leader election + auto-rebalance, no ZooKeeper/etcd/Consul.
Coordination lives entirely in EAV (row locks + SELECT FOR UPDATE CAS + epoch fencing).

Closest analogues are Apache Karaf and Camel K. Both JVM-only until now.

redb.Core — the storage layer underneath. Apache 2.0.
github.com/redbase-app/redb

EAV-style typed object store over Postgres / MSSQL with full LINQ. Schema is a
C# class with [RedbScheme]. Values live in typed columns with FK constraints —
not JSON blobs. SyncSchemeAsync<T>() at startup, no migration files.

[RedbScheme("Order")]
public class OrderProps
{
    public string  Status { get; set; } = "";
    public decimal Total  { get; set; }
}

// Inside a route pipeline:
.ProcessWithRedb("pg-main", async (redb, ex, ct) =>
{
    var id = await redb.SaveAsync(new RedbObject<OrderProps>
    {
        name  = $"Order-{DateTime.UtcNow:HHmmss}",
        Props = new() { Status = "new", Total = 299.99m }
    });
    ex.In.Headers["order-id"] = id;
})
.To("rabbitmq://processed");

Production state

Running at East-West / EWS — a 30-year-old national HoReCa
food distributor in Russia.

~150k orders/month, ~20k B2B customers, 600+ cities
3-node cluster (4 cores / 8 GB / 50 GB SSD per node)
~550 daily users, ~3 months stable, 10–15% CPU under full load
Routes integrate: SAP, Kafka, RabbitMQ, GPS feeds, Mercury / EGAIS / Chestny Znak / FGIS Grain (Russian regulatory systems)

43 NuGet packages, ~8.4k total downloads. Real but small.

What's honest

Bus factor of 1. I'm the solo author of the framework code. Publishing
to find early users and get harsh feedback.

Pro tier exists. Commercial license covers: compiled expression-tree-to-SQL,
parallel materialization, change-tracking diff, schema migrations.
Everything above — Route, Tsak, Core CRUD/LINQ/trees/security/export,
22 transports, hot-reload, cluster — is Apache 2.0 and stays free.

No third-party benchmarks yet. Internal Free-vs-Pro numbers at
redbase.app/results — treat as
"how editions compare on the same machine", not universal claims.

Architecture writeup: redbase.app/architecture

redb.Identity (near-complete, not yet public) — OAuth 2.0 / OIDC server
built on redb.Core. Authorization Code + PKCE, Client Credentials, Device Code,
Refresh Token, PAR, DPoP, backchannel logout, private_key_jwt. Apache 2.0.

Three questions I don't have the answer to

1. Is "another integration framework" the wrong framing?

The gap I described feels real to me — I lived with it for years before building
this. But maybe .NET teams that need Camel just use Camel via NativeAOT interop,
or have given up on the EIP model entirely. Curious what you've actually done.

2. Does "EAV" as a term kill the pitch?

redb.Core uses EAV — and that word triggers people (slow, untyped, joins
everywhere). The design is typed columns + FK constraints + 40+ indexes, not
JSON blobs. But maybe the term itself is a non-starter regardless of the
implementation. Has anyone successfully reframed EAV to a skeptical audience?

3. What makes a Pro/Free split feel fair vs bait-and-switch?

The free tier covers everything you need to build and run production pipelines.
Pro adds performance features (compiled SQL, parallel materialization) and ops
features (change tracking, migrations). Is that split legible from the outside,
or does "compiled queries are Pro" read as "the free tier is intentionally crippled"?

Links


redb.Route	github.com/redbase-app/redb-route
redb.Tsak	github.com/redbase-app/redb-tsak
redb.Core	github.com/redbase-app/redb
Architecture	redbase.app/architecture
Discussions	github.com/redbase-app/redb-route/discussions

Happy to answer technical questions in the comments.

We built an enterprise integration stack for .NET from scratch: EAV + DSL + runtime

rinat kozin — Wed, 13 May 2026 19:35:53 +0000

Three open-source libraries. One coherent stack. All Apache 2.0.

This is the story of what we built, why, and how the three pieces fit together
in a way that surprised even us.

The problem

Enterprise .NET integration in 2026 still looks like this:

EF Core for data — plus a migration file every time a field changes
MassTransit or NServiceBus for messaging — great if you only need message brokers, but IBM MQ, SFTP, MQTT, SQL polling? Custom adapters, every time
Kubernetes + etcd for clustering — because "that's just how you do it"

We needed all three. We built all three. And then we noticed they could share
the same storage layer — and everything clicked.

Layer 1: redb.Core — typed EAV without the pain

github.com/redbase-app/redb · Apache 2.0

RedBase (REDB) - Entity Database for .NET | LINQ, Trees, Aggregations

Not a key-value store. Real objects, real queries. LINQ, trees, aggregations — native SQL.

redbase.app

EAV (Entity–Attribute–Value) has a bad reputation — and for good reason.
Raw EAV means losing types, losing LINQ, losing your mind.

redb.Core is typed EAV. You define a schema as a plain C# class:

[RedbScheme("Employee")]
public class EmployeeProps
{
    public string  Department { get; set; } = "";
    public decimal Salary     { get; set; }
    public int     Level      { get; set; }
}

That attribute is the entire schema definition. No DbContext. No Add-Migration.
No SQL files. Call SyncSchemeAsync<EmployeeProps>() once at startup — done.

// Save
await redb.SaveAsync(new RedbObject<EmployeeProps>
{
    name  = "Alice",
    Props = new() { Department = "Engineering", Salary = 95000m, Level = 3 }
});

// Query — full LINQ, compiled to SQL
var seniors = await redb.Query<EmployeeProps>()
    .Where(e => e.Level >= 3 && e.Salary > 80000m)
    .OrderByDescending(e => e.Salary)
    .ToListAsync();

GroupBy, window functions, tree queries (CTE-based), aggregations — all there.
Add a field to EmployeeProps → call SyncSchemeAsync → it's live. No migration.

Why EAV? Because the schema is runtime data. You can add attributes, create
new object types, and restructure relationships without touching the database schema.
This matters a lot for the other two layers.

Layer 2: redb.Route — Apache Camel for .NET

github.com/redbase-app/redb-route · Apache 2.0

If you know Apache Camel, you know the model: From → Process → To.
redb.Route brings that model to .NET — in pure C#, no XML, no JVM.

// Kafka → filter → enrich → RabbitMQ
From("kafka://orders?groupId=svc&brokers=localhost:9092")
    .Filter(Header("type").isEqualTo("new"))
    .Retry(3)
    .To("rabbitmq://events?host=localhost");

22 transports out of the box: Kafka, RabbitMQ, IBM MQ, gRPC, HTTP, Redis,
MQTT, S3, SFTP, FTP, SQL, TCP, WebSocket, SignalR, Azure Service Bus,
Elasticsearch, Firebase, LDAP, Mail, AMQP 1.0, Quartz, File.

30+ EIP patterns as first-class DSL: Content-Based Router, Splitter,
Aggregator, WireTap, Multicast, Recipient List, Dynamic Router, Resequencer,
Scatter-Gather, Claim Check, Idempotent Consumer, Saga, Circuit Breaker,
Throttle, Retry, Dead Letter, and more.

Compiled expression engine. ${header.x}, ${header.x++}, arithmetic,
JSONPath, XPath — all compiled to Func<IExchange, T> via
System.Linq.Expressions at route-build time. No interpreter overhead,
results cached per route.

A real pipeline from production — HTTP entry → validate → dedup →
Choice by priority → RabbitMQ RPC → AMQP RPC → gRPC RPC →
SQL INSERT + SELECT → WireTap(Kafka, File) → response:

From("http:0.0.0.0:5088/api/demo?inOut=true")
    .ConvertBody<string>()
    .Throttle(10)
    .ValidateJsonSchema(messageSchema)
    .IdempotentConsumer(e => e.In.GetHeader<string>("traceId"), repo)
    .Choice()
        .When(Header("priority").isEqualTo("high"))
            .SetHeader("fastTrack", "true")
        .Otherwise()
            .SetHeader("fastTrack", "false")
    .EndChoice()
    .To("direct://pipeline");

The integration point: Route reads and writes EAV

This is where it gets interesting.

The Route DSL has a .ProcessWithRedb(...) step that gives you a named
IRedbService instance directly inside a pipeline step:

// Inside a route — full EAV access without leaving the pipeline
.ProcessWithRedb("pg-test", async (redb, exchange, ct) =>
{
    var id = await redb.SaveAsync(new RedbObject<DemoItemProps>
    {
        name  = $"Demo-{DateTime.UtcNow:HHmmss}",
        Props = new() { Title = "Pipeline result", Priority = 7 }
    });
    exchange.In.Headers["saved-id"] = id.ToString();
})

// Load what we just saved
.ProcessWithRedb("pg-test", async (redb, exchange, ct) =>
{
    var id   = long.Parse(exchange.In.GetHeader<string>("saved-id")!);
    var item = await redb.LoadAsync<DemoItemProps>(id);
    exchange.In.Headers["title"] = item?.Props?.Title;
})

// LINQ query inside a pipeline step
.ProcessWithRedb("pg-test", async (redb, exchange, ct) =>
{
    var results = await redb.Query<DemoItemProps>()
        .Where(p => p.Priority > 3)
        .Take(5)
        .ToListAsync();
    exchange.In.Headers["count"] = results.Count.ToString();
})
.Log("Found ${header.count} high-priority items");

The transport doesn't matter. Swap Kafka for IBM MQ for an HTTP webhook —
the EAV read/write logic inside .ProcessWithRedb(...) stays unchanged.

Layer 3: redb.Tsak — the runtime container

github.com/redbase-app/redb-tsak · Apache 2.0

Drop a .dll or a .tpkg (ZIP with manifest + DLLs) into a folder.
Tsak loads it, wires the DI container, starts the routes. Hot-reload:
replace the file while running — zero downtime.

REST API + CLI + Blazor dashboard for management.

The cluster has no ZooKeeper, no etcd, no Consul.

Leader election, distributed locks, and node registry live entirely in EAV:

RedbLeaderElection
  → TTL-based row lock in EAV: "{groupName}:leader"
  → SELECT FOR UPDATE (atomic CAS)
  → epoch counter — stale leaders rejected by fencing

RedbDistributedLock
  → TryAcquireAsync: check existing lock → if expired → AtomicTakeover
  → AtomicTakeover: transaction + row-level lock, no races

RedbNodeRegistry
  → node records in EAV (TsakNodeProps)
  → registration protected by "{groupName}:node-register-lock"
  → serializes simultaneous startups

Behind ILeaderElection / IDistributedLock / INodeRegistry — swap in
a K8s Lease implementation without changing anything else.

The cluster is the EAV database. No extra infrastructure.

Why it fits together

┌─────────────────────────────────────────────────────┐
│                   redb.Tsak                         │
│  (hot-reload runtime, cluster, REST/CLI/Blazor UI)  │
│         cluster state stored in redb.Core EAV       │
├─────────────────────────────────────────────────────┤
│                  redb.Route                         │
│  (22 transports, 30+ EIP, compiled expressions)     │
│       .ProcessWithRedb() ── reads/writes EAV        │
├─────────────────────────────────────────────────────┤
│                  redb.Core                          │
│  (typed EAV, LINQ, no migrations, Postgres/MSSQL)   │
└─────────────────────────────────────────────────────┘

The storage layer (EAV) is also the cluster coordination layer
The pipeline engine (Route) speaks directly to the data layer (EAV) without a separate service, separate DB, or separate connection
The runtime (Tsak) hosts Route assemblies with hot-reload and manages cluster membership through the same EAV instance

One PostgreSQL (or SQL Server) database. No Redis for caching, no ZooKeeper
for coordination, no separate message store for pipeline state.

Numbers from production

Running at EWS — e-commerce platform:

~550 daily active users, ~150,000 orders/month
3-node Tsak cluster
Pipelines: Kafka → filter/enrich → RabbitMQ, SQL outbox → HTTP webhooks, SFTP polling → CSV → SQL upsert, Timer → SQL → Mail

Zero-downtime deploys: replace .tpkg → Tsak reloads the module → routes
restart → in-flight messages complete on the old instance.

Links


redb.Core (EAV)	github.com/redbase-app/redb
redb.Route (DSL)	github.com/redbase-app/redb-route
redb.Tsak (runtime)	github.com/redbase-app/redb-tsak

All Apache 2.0. Issues and PRs welcome.

Next in the series: deep dive into the compiled expression engine —
how ${header.x++} becomes a Func<IExchange, T> at build time.

DEV Community: rinat kozin

Enterprise Integration Patterns in .NET, the deep-dive series — Part 1: the four in-memory channels (and the Exchange they carry)

Track A — the in-process foundation (8 components)

Track B — the Enterprise Integration Patterns (~30, across 41 processors)

Track C — the expression & predicate engine (its own article, and it earns it)

Track D — the 22 connectors, one article each

The Exchange — the heart, and it isn't simple

1. In vs Out, and the Pattern

2. Properties vs Headers — the distinction that leaks bugs

The well-known keys the framework itself writes

3. The exception travels in-band

4. ExchangeId is stable across clones

5. The DI scope — and four ways to copy an exchange

The gotcha: Clone() does NOT deep-copy the Body

Two APIs on purpose

The four channels — two axes

direct:// — a method call wearing a URI

seda:// — the async queue, in detail

The parameters

concurrentConsumers — throughput, at the cost of order

size — bounded vs unbounded, and why you almost always want bounded

timeout — an honesty note

Graceful shutdown — seda drains, it doesn't drop

The durability caveat

The transaction trap, stated once and for all

direct-vm:// and vm:// — the same two, across module boundaries

Picking a channel

What's next

Links

RedBase / redb.Route / redb.Tsak 3.0.0 shipped

Why our Free was so far behind Pro — and what we just shipped in RedBase 3.0.0 (with the actual SQL)

30-second background

How we got here — the two paths that existed before 3.0.0

Pro path (since ~2024) — compiled in C

Free path (until 3.0.0) — interpreted on the database side

Why the gap existed for so long

What 3.0.0 actually changes

1. MSSql Free hit full v2-pvt parity — 145/145

2. Auto-deploy of the v2-pvt bundle

3. Base-field pushdown — the 894 ms → 11 ms one

4. Nested-dict accessor short-circuit

5. What landed in Pro this cycle

"Wait — Free builds SQL dynamically inside plpgsql. What about SQL injection?"

Pro side (C#) — boring and safe

Free side on PostgreSQL (plpgsql) — three layers, on purpose

Free side on MSSql (T-SQL) — the same three layers, different primitives

Summary

The polyglot facet API — Free's one structural advantage

The honest matrix

Migration notes

Known gaps I'd like help finding

Try it

From Closed Internal Stack to Open-Source Ecosystem: I Finally Shipped Three Years of .NET Infrastructure

Why this exists (the actual pain)

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

What's next (already in flight, not on a wish-list)

An EF Core alternative for .NET apps with complex object graphs — full LINQ, no migrations, no DbContext

What redb.Core actually is

Object graphs in one call

What the LINQ actually compiles to

Why bulk save is so fast — two tables, two streams

Change tracking without DbContext (Pro)

Production deployment — the numbers

Real workload, real timings

What's actually in the database

What would EF Core look like here?

What EF Core does with complex objects (vs what RedBase does)

The query engine: free vs Pro

Show me the SQL it generates

When this fits and when it doesn't

What else is in the box

What's coming next

This is maybe 10% of what's in there

Links

redb.Route — Apache Camel for .NET: 22 transports, 30+ EIP patterns, compiled DSL

The shape of every pipeline

22 transports as first-class URI schemes

1. `In` vs `Out`, and the `Pattern`

2. `Properties` vs `Headers` — the distinction that leaks bugs

4. `ExchangeId` is stable across clones

The gotcha: `Clone()` does NOT deep-copy the Body

`direct://` — a method call wearing a URI

`seda://` — the async queue, in detail

`concurrentConsumers` — throughput, at the cost of order

`size` — bounded vs unbounded, and why you almost always want bounded

`timeout` — an honesty note

Graceful shutdown — `seda` drains, it doesn't drop

`direct-vm://` and `vm://` — the same two, across module boundaries

Testing without a broker — `mock://`