Manifold-BT vs NautilusTrader

Built for the research loop

Manifold-BT is a research engine, and everything about it is tuned for iteration speed. It ingests real market data, evaluates signals vectorized over the full series in Rust, then runs a sequential pass for fills and PnL on an Apache Arrow core, with realistic execution on by default: market-impact slippage, funding on perpetuals, partial fills, and next-bar fills. The part that matters most is the parameter sweep: the whole grid is a single native call that fans out across every core, with GPU as the next step up. Testing thousands of variants of an idea stays interactive, which is exactly where research lives.

NautilusTrader is a production-grade, event-driven trading platform, and a very good one. It replays historical quotes, trades, and order-book deltas at nanosecond resolution with configurable latency and fill models, and the same event loop drives live trading through venue adapters. That is powerful, and it is aimed at deployment: it is the fidelity and parity you want when a strategy goes live. It also means a platform to learn and stand up, an engine, a data catalog, venue configuration, and Strategy classes, before your first result, which is a lot of surface area if all you want to do right now is test ideas.

Side by side

Why a research engine wins the parameter search

Validating a strategy is not one backtest, it is thousands: sweep the grid, find the stable plateau, then repeat it for every walk-forward fold. This is where the two designs pull apart. An event-driven engine processes one event at a time, in order, exactly as it would live, which is the highest-fidelity way to simulate a single run and the reason it is the right tool for deployment. But it pays that full event overhead on every run, so a grid search means running the whole backtest thousands of times over.

Manifold-BT is built the other way for exactly this workload. Signals are computed vectorized over the whole series, the grid goes to the Rust core as one call, data is loaded once, and combinations fan out across all cores with no Python in the loop and GPU available on top. Same idea, far fewer round trips, and the search stays interactive at grid sizes where a per-run event loop becomes a batch job:

import manifoldbt as mbt
from manifoldbt.indicators import close, ema

# One strategy, two swept parameters
fast, slow = ema(close, mbt.param("fast")), ema(close, mbt.param("slow"))
strategy = (
    mbt.Strategy.create("ema_cross")
    .signal("fast", fast)
    .signal("slow", slow)
    .size(mbt.when(fast > slow, 1.0, 0.0))
)

# The whole grid runs as one native call across every core (GPU optional).
# config + store are set up once, elsewhere.
sweep = mbt.run_sweep(
    strategy,
    param_grid={"fast": range(5, 100), "slow": range(20, 300)},
    config=config, store=store,
)
best = sweep.best("sharpe")

Stack walk-forward, 2-D heatmaps, and Monte Carlo on that same engine and the whole research loop stays fast. When the map runs in seconds you actually draw it, change a threshold, and run it again, which is the habit that keeps a strategy from overfitting.

When NautilusTrader is the right call

One case, clearly: you are going live. If you need order-book and latency modeling, nanosecond time, multi-venue adapters, and the guarantee that the code you validated is the code that trades, NautilusTrader is built for exactly that and Manifold-BT is not, on purpose. That is a real and hard problem, and it is a different problem from finding the edge. The clean setup uses both: research and stress-test the idea fast in Manifold-BT, then implement the survivor on NautilusTrader for live-parity execution.

Which should you pick?

If the work in front of you is research, and for most people it is, choose Manifold-BT: real market data in, realistic costs by default, and large parameter sweeps, walk-forward, and Monte Carlo that finish in seconds, including on GPU, from a library you install in one line. Reach for NautilusTrader at the point you go live and need backtest-to-live parity with order-book fidelity. Find the edge first, deploy it second.

Frequently asked questions