Benchmarks

Performance data,not marketing claims.

Historical CerbiStream comparisons plus a focused August 2026 verification of the current SDK governance paths and the live CerbiShield v1.10.80 Gateway. Every new number is paired with its workload and deployment conditions.

65
Benchmarks
66ns
Plain Logging
≈4×
Lower DIY Encryption Latency
8.2–8.9×
Lower DIY Redaction Latency
View Full Results on GitHub

Benchmarks run with BenchmarkDotNet on .NET 9, Release build, no debugger attached. DIY comparisons use framework-native approaches to replicate the same capability. Results are reproducible from the linked repository.

Verified August 27, 2026

Current release evidence

These focused tests answer two different questions: what the in-process SDK costs for a ten-field event, and what one shipped Azure Gateway replica processed under a bounded OTLP load. Each result is paired with practical scale and buyer context below. They are baselines for evaluation, not universal capacity guarantees.

27.40 µs
CerbiStream 2.0.126 full SDK governance

The released NuGet package contains the optimized .NET SDK path: approximately 4.2× faster than the same source workload before optimization, with allocation reduced from 12.1 KiB to 2.52 KiB per event. A no-op sink isolates governance work.

Review the merged benchmark changeInstall the verified NuGet release
0.27–0.28 µs
Explicit relaxed SDK path

Mean per event across the same three runs and payload shape. Approximately 1.14 KiB allocated per operation. This fast path is not equivalent to full validation.

19.1K–19.5K
Gateway events/sec

Three live 20-second runs with 50-event batches, one 0.5-vCPU / 1-GiB replica, signed observe-mode policy, internal HTTPS, and dormant debug export. HTTP 200 for every measured request; zero client errors.

What these numbers mean in practical scale

≈36.5K operations/sec

The arithmetic ceiling for one continuously busy core at 27.40 µs per SDK governance operation. Real applications share CPU with business logic, logging sinks, networking, and the runtime.

≈9.6 GB less allocation

Temporary managed allocation avoided per one million governed SDK events versus current master before optimization. This reduces garbage-collection pressure; it is not storage or customer memory reserved.

≈38K events/sec/vCPU

The Gateway result normalized from 19.1K–19.5K events/sec on a 0.5-vCPU replica. This is useful sizing context, not proof of linear scaling across replicas or destinations.

≈35.9 GiB/hour/vCPU

Equivalent to about 25.2 TiB over a continuously sustained 30-day month at 10.2 MiB/sec/vCPU. This is input-rate arithmetic—not a plan entitlement, forwarding SLA, or recommended deployment size.

Gateway batching materially changes throughput and tail latency. The 50-event case reached p95 194–197 ms and p99 285–291 ms while CPU reached the half-core ceiling; peak working set was about 79 MiB. No downstream destination was active, so this is not a forwarding-path SLA.

Download raw evidence

Industry context—not a head-to-head test

Normalized for its 0.5-vCPU allocation, the bounded Gateway run processed about 10.2 MiB/sec per vCPU—roughly 35.9 GiB/hour per vCPU. Datadog publishes conservative Observability Pipelines sizing guidance of about 10 MiB/sec/vCPU for approximately 512-byte unstructured events and 25 MiB/sec/vCPU for approximately 1.5-KiB structured events in a reference pipeline using 12 processors. This puts the measured Cerbi result in the same performance order of magnitude as a major commercial pipeline planning baseline—but it does not establish product equivalence or a winner.

The workloads are materially different: Cerbi's measured events averaged about 278 bytes, used observe mode, and had no active downstream destination. Destination behavior, processing rules, event size, batching, durability, and scaling can all change throughput.

Read the referenced Datadog sizing guidance

Compared with familiar .NET loggers

The simple version: familiar logging speed, with governance built around it.

Serilog, NLog, Microsoft Logging, and log4net are capable, established logging choices. Cerbi is not claiming they are slow or that customers must replace them. The measured distinction is that plain logging stayed in the same narrow performance band, while Cerbi's integrated control paths avoided much of the overhead seen in the benchmark's custom encryption and redaction wrappers.

Buyer questionWhat the test measuredWhat it means in normal language
Does ordinary logging stay competitive?63.99–67.76 ns/event across NLog, Serilog, CerbiStream, Microsoft Logging, and log4net; CerbiStream measured 66.24 ns.All five landed in a narrow six-percent band. In this no-op test, choosing CerbiStream did not create a meaningful plain-logging penalty.
What happened in the 1,000-event batch?64.35–65.74 ns/event across the five paths; CerbiStream was 2.2% behind the fastest measured result.The batch results were effectively clustered. The destination and application workload will matter far more than this small measured spread.
What changes when sensitive-data controls are added?CerbiStream measured 90.76 ns for redaction versus 745.51 ns for the NLog DIY wrapper and 811.67 ns for the Serilog DIY wrapper in this suite.The integrated path was about 8.2–8.9× faster than the specific custom wrappers tested. This is not a claim against every third-party plugin or possible implementation.
Is the current full governance path practical?CerbiStream 2.0.126 measured 27.40 µs/event and 2.52 KiB/event—4.2× faster with 79% less allocation than the same pre-optimization workload.The current release leaves substantially more application headroom. It still performs more work than plain logging because it evaluates policy and enriches the event.

Does this support an enterprise-toolset claim?

It supports saying Cerbi has enterprise-scale performance engineering and a credible high-throughput design. Throughput alone does not prove enterprise readiness. That judgment also depends on security boundaries, tenant isolation, reliability, RBAC, change control, evidence, support, and recovery behavior—areas documented separately in the architecture and security sections.

Key findings

66 ns
Plain Logging
Same measured band

Comparable plain-path result in the historical comparison suite

64 ns
Encrypted Logging
vs DIY middleware

Integrated encryption measured about 4× lower latency than the equivalent custom wrappers in this suite

91 ns
PII Redaction
vs DIY middleware

Integrated redaction measured 8.2–8.9× lower latency than the NLog and Serilog DIY wrappers in this suite

0 ns
Design-Time
Zero runtime cost

Roslyn analyzers catch issues at build time

Plain Logging Performance

This historical suite compares basic structured logging paths. CerbiStream and its governance SDKs are free to install and use; full runtime governance has measurable compute cost, reported separately in the current-release evidence above.

Verdict: Plain logging was comparable in this historical suite. The CerbiStream SDKs are free; full runtime governance has a measurable compute cost. See the current-release verification above.

LoggerMean (ns)AllocatedRatio
NLog63.9956 B0.95x
Serilog65.1856 B0.96x
CerbiStream66.2456 B1.00x
MS Logging67.6856 B1.02x
log4net67.7656 B1.02x

What the core packages include

This matrix describes built-in core-package behavior—not everything available through each logger's extensions, enrichers, filters, or third-party ecosystem.

FeatureCerbiStreamSerilogNLoglog4netMS Logging
Structured Logging
Async Sinks
Built-in Encryption
PII Auto-Redaction
Schema Validation
Governance Profiles (JSON)
Design-Time Analyzers
Required/Forbidden Fields
Governance Scoring
Built-in
Not built into core
Limited

Cerbi's distinction is the integrated governance lifecycle: policy, required and forbidden fields, redaction, scoring, analyzers, and evidence are designed to work together. Other loggers may add individual controls through extensions or custom code.

Test Environment
Framework.NET 9.0 (RyuJIT x64)
OSWindows 11
CPUIntel i9-9900K
ToolBenchmarkDotNet 0.15.8
SinkNo-op (isolated)
Iterations10 measured, 3 warmup
Reproduce These Results
git clone https://github.com/Zeroshi/CerbiStream.BenchmarkTests
cd CerbiStream.BenchmarkTests
dotnet run -c Release --project Cerbi-Benchmark-Tests/Cerbi-Benchmark-Tests.csproj

Results appear in BenchmarkDotNet.Artifacts/results/

Ready to govern your logs?

Start with CerbiStream in under 60 seconds, or explore the benchmark repository.

CerbiStream + analyzers free on NuGet | CerbiShield licensed by governed event volume

NEXTChoose your next proof

Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield keeps policy, rollout, violations, audit, and evidence under one governance program.

One initial workload/Customer-hosted in Azure/Existing destinations remain
Benchmarks | Cerbi