Run YAML decisions directly on incoming event streams.

BlazeRules evaluates your rules at the first layer of data flow, so applications can approve, block, review, route, or suppress events before teams build full filtering pipelines around them.

~211K Max JSON rec/s at 15KB payload
~3.0 GiB/s Max observed JSON input throughput
~654K Max Arrow IPC records/sec observed
PIPELINE_MONITOR_01
INGEST HTTP | FILES
BLAZERULES CORE
Compile
Project
Scan
Reduce
APPROVE
REVIEW
BLOCK
654K MAX ARROW IPC RECORDS/SEC

Stop paying per record.

Instead of pushing every raw event into a warehouse, stream processor, or custom filter service, BlazeRules compiles the rule set once and evaluates batches as projected columns.

Standard Row Engine

MEMORY Scattered object states
EXECUTION Nested pointer chasing
PARALLELISM Thread-locking callbacks
CACHE MISS RISK

BlazeRules Vector

MEMORY Contiguous Columnar Buffers
EXECUTION SIMD Masked Evaluation
PARALLELISM Lock-free Batch Partitioning
CACHELINE OPTIMIZED

The Data Plane Pipeline

Rules, windows, lookups, model scores, and routing outputs stay in one batch-first decision path.

STEP 01
input
Source Polling

Reusable batch buffers

STEP 02
dataset
Batching

Transposing Rows to Columns

STEP 03
settings_suggest
Normalization

Schema enforcement

STEP 04
memory
SIMD Kernel

Vector rule execution

STEP 05
list_alt
Aggregation

Window state persistence

STEP 06
send
Egress Dispatch

Grouped decisions

Choose your interface.

terminal

Python SDK

import blazerules as br

engine = br.Engine(rules="config.yaml")
results = engine.evaluate_ndjson(
    input_file="events_10M.json",
    batch_size=50000
)

print(f"Processed: {results.stats.records}")

Use Python when your app already owns the batch and wants decisions without a service hop.

dns

Local Agent

$ blazerules_agent --source http
[INFO] Listening on :8080
[INFO] Hot-loading rules... OK
[INFO] Batch workers ready
[METRIC] throughput: batch-mode

Use the local agent when apps need to send logs, files, or HTTP events into a shared rule evaluator.

hub

Stream Adapter

SHARD 01 AFFINE
SHARD 02 AFFINE
SHARD 03 PROCESSING...

Use queue or stream consumers when a source should poll, batch, evaluate, and hand compact decisions to downstream app logic.

history

Velocity Windows

Calculate rolling counters and sums over sliding windows without an external database.

search

Lookup Sets

CSV-backed string, integer, and IPv4 CIDR lookup sets compiled into fast membership checks.

account_tree

Nested Payloads

Nested dotted fields and array_any rules project only referenced payload paths into columns.

neurology

ONNX Integration

Optional ONNX model_score rules can add model outputs as decision signals when enabled.

refresh

Hot Reload

Compile and validate a candidate ruleset, then swap it between batches without interrupting the active engine.

fork_right

Grouped Routing

Expose decisions and grouped row indices so callers can bulk-route APPROVE, REVIEW, BLOCK, or custom outcomes.

Local Mac Stress Matrix

Measured on the local 36GB / 12-core Mac stress setup with the broad nested rules corpus. Records/sec counts evaluated events; GiB/s counts input volume. Numbers are engine-side observations, not cloud guarantees.

Configuration

Rules: 1,047 | Payloads: nested JSON/Arrow/Avro/Protobuf | Host: local Mac 36GB/12-core

Engine Input Throughput (GiB/s)

JSON 15KB+ ~3.0 GiB/s · ~211K rec/s
Arrow IPC peak ~3.1 GiB/s · ~654K rec/s
Avro median ~0.65 GiB/s · ~417K rec/s
Protobuf median ~0.48 GiB/s · ~427K rec/s

JSON Payload Width Sensitivity (GiB/s)

2KB
5KB
10KB
15KB+

Shift-Left Infrastructure Economics

Reduce downstream pressure by filtering and compacting events at the data-plane edge.

analytics Economic Summary
Volume Reduction Up to 80%
Data Privacy Zero PII Egress
Compute Model Consolidated
Legacy Pipeline
100% RAW PAYLOADS
arrow_downward
CLOUD SIEM / WAREHOUSE
High Metered Cost
BlazeRules Shift-Left
100% RAW PAYLOADS
DETERMINISTIC FILTER
arrow_downward
20% HIGH-VALUE SIGNALS
Lower Infrastructure Cost

Where BlazeRules fits.

BlazeRules is the decision layer between raw ingestion and expensive downstream systems. It is not a database, not a full stream processor, and not a case-management suite.

A rule engine data plane, not another stream processor or database.

BlazeRules is built for low-latency decision density. Unlike analytical engines or general-purpose stream processors, it optimizes for stateful rule evaluation at line-rate.

settings_input_component Transport Streams / CDC / Webhooks
bolt BlazeRules Real-time Decisions
database Storage Warehouse / SIEM
account_tree Workflows Case Management

BlazeRules sits between ingestion and persistence, where latency-sensitive decisions are made before storage and workflow systems receive the event.

BlazeRules Engine
Peripheral Systems

Positioning Radar

While other tools offer broad capabilities, BlazeRules focuses on the high-density intersection of stateful logic and extreme performance.

  • check

    vs BRMS (Drools, Camunda)

    BlazeRules avoids row-by-row rule dispatch and keeps deterministic decisions in a native batch evaluator.

  • check

    vs Flink (Stream Processors)

    Simpler state management. No complex watermarking or windowing logic for pure rule matching.

  • check

    vs OLAP (DuckDB, ClickHouse)

    True push-based execution. Decisions fire on arrival, not on query-time polling.

Decision Density Distributed State Authoring UX Analytical Depth

How BlazeRules compares

Category Drools / BRMS Apache Flink BlazeRules SIEM Suites
Primary Value Complex business logic authoring for non-devs. Massive scale windowing and aggregations. High-throughput decision plane for engineers. Integrated log management and alerting.
Latency L50 > 10ms (JVM overhead) 20ms - 100ms (Network shuffle) Low in-process batch latency > 500ms (Indexing delay)
Language DRL (Custom), Java Java, Scala, SQL YAML / C++ and Python SDK Proprietary Query DSL
When not to use When you need >50k EPS or containerized footprints. When data fits on one node or state is simple. When you need interactive historical exploration. When custom logic requires external API lookups.

BlazeRules vs. Traditional BRMS

Legacy Business Rule Management Systems (BRMS) were designed for the "Enterprise Service Bus" era. They prioritize non-technical authoring interfaces which lead to bloated XML/JSON structures and heavy interpretation overhead. BlazeRules treats rules as compiled code.

[rule: rate_limit_v1]
match: event.type == "login"
state: cache.increment(event.ip, 1m)
action: state.val > 10 ? reject() : allow()

Decisions vs. Analytics

Modern databases like ClickHouse are incredible at answering "What happened in the last hour?". However, using a database to decide "Should I drop this packet right now?" introduces unacceptable polling latency. BlazeRules is a **push-first** system.

Stream Processors: The Overhead Problem

Stream processors are powerful when logic needs broad distributed joins, replays, and topology management. For many deterministic filtering paths, the cluster and checkpointing overhead can be larger than the rule evaluation itself.

Why Not Just Use a SIEM?

SIEM tools are optimized for search and long-term storage. BlazeRules is designed to prevent incidents by taking action before the data reaches the SIEM, while still emitting compact decisions and audit records downstream.

Ready for a benchmark?

Run the benchmark harness against your current stack and compare throughput, latency, and payload sensitivity in your own environment.

terminal View docs Contact licensing