Most solo quants assemble their stack backwards: they start with a backtesting framework, discover its data model fights their data vendor, bolt on a database that fits neither, and end up maintaining glue code instead of researching. This guide lays out the stack in dependency order — data first, alpha last — with what each layer costs and where spending money actually buys you research velocity.
This is the setup we’d build today for systematic research on daily-to-intraday horizons at individual scale. High-frequency market making has different answers at every layer.
The stack at a glance
| Layer | Boring default | When to upgrade |
|---|---|---|
| Market data | One good API vendor (equities/crypto per your market) | Point-in-time fundamentals; tick history |
| Storage | Parquet files + DuckDB | ClickHouse/TimescaleDB when data outgrows one machine |
| Research | Python, Jupyter, pandas/Polars | Polars or Rust extensions when pandas becomes the bottleneck |
| Backtesting | vectorbt or a ~500-line engine you wrote and understand | Event-driven engine only when strategy logic demands it |
| Compute | Your workstation | One cloud GPU box, rented hourly, for ML experiments |
| Execution | Broker API (IBKR-style) + a VPS | Colocation is a business decision, not a research one |
| Monitoring | Cron + logs + one alerting channel | Grafana when you run more than two live strategies |
Layer 1: Market data — own your pipeline, rent the feed
The single highest-leverage decision in the stack. Three rules that survive contact with reality:
Store the raw vendor payloads. Disk is cheap; re-downloading history after a vendor drops an endpoint, changes a symbology, or you churn off their plan is somewhere between expensive and impossible. Every API response lands in an append-only raw zone (compressed JSON or Parquet) before any transformation touches it.
Split prices from fundamentals mentally and financially. End-of-day and intraday price data is commoditized — API vendors in the $30–$250/month bracket cover it well for US equities and crypto. Point-in-time fundamentals (as-reported, with restatement history) are not commoditized, and cheap fundamental feeds silently backfill restated numbers — a look-ahead bias machine. If your strategies use fundamentals, this is where the real data budget goes; if not, don’t pay for them.
Survivorship is the bias that kills retail backtests. Whatever vendor you choose, confirm delisted securities are in the historical universe, and test it: query a ticker that went bankrupt and check the data is there. Our market data vendor guide goes deep on this.
Layer 2: Storage — Parquet + DuckDB until it hurts
The 2026 answer for a one-person shop is boring and excellent: partitioned Parquet files on local NVMe, queried with DuckDB.
- Parquet is vendor-neutral: every tool in the ecosystem reads it, so no migration ever strands your data.
- DuckDB runs full analytical SQL over those files in-process — no server, no ops, and on a modern workstation it scans years of daily bars in milliseconds and single-name tick days in seconds.
- Partition by date (and by symbol only if you routinely query single names); compress with zstd; keep a manifest of what’s loaded.
You upgrade to a real database server when one of these becomes true: multiple processes need concurrent writes, the working set outgrows one machine, or you’re running continuous intraday ingestion. At that point the candidates are ClickHouse, TimescaleDB, QuestDB, or kdb+ — compared honestly in our tick database guide.
Layer 3: Research environment — optimize for iteration speed
Python remains the only defensible default. The 2026 refinements:
- Polars over pandas for anything heavy. The API is stricter, the speedups on groupbys and joins are routinely 5–20× on research workloads, and it shares Arrow memory with DuckDB so data moves between them without copies.
- One repository, one environment. A single
uv-managed project with your data loaders, feature library, and notebooks beats a constellation of per-idea folders. Your feature definitions are your real IP; version them like production code. - Notebooks are for exploration, modules are for truth. The moment a computation matters, it moves from notebook to a tested function. Every serious research shop converges on this rule after their first irreproducible result — skip the learning fee.
Layer 4: Backtesting — the layer where honesty lives
Framework choice matters less than the discipline around it, but the practical options in 2026:
- vectorbt for fast vectorized scans over signal grids — ideal for the “is there anything here at all?” phase.
- A small event-driven engine you wrote yourself (a few hundred lines) for anything approaching production. Not because existing engines are bad, but because every assumption you didn’t write is an assumption you can’t audit — and fills, costs, and timing assumptions are where backtests lie.
- Whatever you use, hold the line on the big four: point-in-time data, explicit transaction costs, no same-bar execution on signal bars, and a untouched out-of-sample period. The papers that score highest on empirical rigor across our topic hubs share exactly these habits; so should you.
Layer 5: Compute — rent spikes, own the baseline
A capable workstation (fast NVMe, 64–128GB RAM, a mid-range GPU) covers 90% of systematic research. For the ML-heavy remainder — hyperparameter sweeps, deep models on intraday data — hourly cloud GPUs (the spot/community tier of the GPU cloud market) are dramatically cheaper than owning hardware you use in bursts. The workflow that keeps costs sane: develop and debug locally on subsampled data, rent for full-scale runs, pull artifacts back, kill the instance. If your monthly rental bill persistently exceeds the amortized cost of a used workstation GPU, buy the GPU.
Layer 6: Deployment — a $10 VPS and a kill switch
For daily-to-hourly strategies: a small VPS in a reliable region, your strategy as a systemd service or container, orders through your broker’s API, and — non-negotiable — an independent kill switch: a separate process that flattens positions if the strategy stops heartbeating or drawdown breaches a hard limit. Latency optimization below the hundreds-of-milliseconds level is wasted effort at these horizons; reliability engineering is not.
What it costs (September 2026, order-of-magnitude)
- Floor (~$50/month): one data API, local storage, your existing computer, free-tier monitoring. Fully sufficient for daily-frequency equities/crypto research.
- Comfortable (~$200–500/month): better data (intraday history, a fundamentals feed), a VPS, occasional GPU rental.
- The trap: paying for infrastructure before a strategy earns it. Every layer above the floor should be purchased in response to a specific bottleneck, not in anticipation of one.
Prices and tool choices dated September 2026; verify before committing. This guide contains no sponsored placements — if that ever changes, it will be disclosed inline.