Tick data, order books, decades of history.
Arc is the columnar analytical database for quant teams, market makers, and trading desks who run on tick data and backtests. Microsecond resolution. Open Parquet. Standard SQL. None of the per-core licensing.
Single Go binary. Open Parquet. Standard SQL.
The shape of the problem
Tick storage and backtesting infrastructure have looked the same for two decades. Buy kdb+ for the speed, accept the per-core licensing, accept the proprietary q language, accept that every new quant onboards through six weeks of learning q before they can write their first query.
Or move research workloads to a cloud warehouse to escape the kdb+ license, and discover that re-running a year of historical backtests against Snowflake or BigQuery generates a query bill that nobody wants to put in front of the COO.
Or build on Postgres and Timescale, hit the cardinality and write-rate wall as venues add instruments, and start dropping resolution or tick types to stay under the limits.
The execution hot path earns its cost. Tick storage, backtesting, and research do not.
Arc is the analytical store for everything that is not the execution hot path. Tick history, order book reconstruction, backtesting, market microstructure, post-trade analysis, compliance reconstruction. Standard SQL. Open Parquet. On storage you already own.
Built for the workloads a real trading floor runs
Tick storage at venue scale
Active venues generate billions of ticks per day across thousands of instruments. Arc ingests at sustained rates up to 19.9M records/sec on a single instance, with microsecond timestamps preserved end to end. The tick history is queryable about 100 milliseconds after it lands.
Order book reconstruction and replay
Order book data is even more demanding than tick data. Every order, modification, and cancellation is an event. Arc stores the full event stream as columnar Parquet, partitioned by time, and replays a specific microsecond window with SQL. Backtests against historical book state become a query, not a custom replay pipeline.
Backtesting on decades of history
Backtesting is where research budgets are won or lost. Arc stores decades of tick history as ZSTD-compressed Parquet on object storage, 5-7x smaller than raw. Re-running a strategy across years of history costs object-storage prices plus the compute you choose, not a per-query meter or a per-core license.
Quant research and notebook integration
Arc's open Parquet format is native to Pandas, Polars, PyArrow, and every other tool a quant uses in a notebook. No driver, no proprietary client, no conversion step. The same data the desk queries is the data the research team reads into a notebook.
Post-trade analysis and compliance
Reconstructing exactly what a desk saw and what executed against it, at microsecond resolution, across the full retention window, is the core of post-trade and compliance work. Arc holds the full archive in open Parquet, queryable in SQL, indefinitely, for the price of cold storage.
What Arc gives a trading firm
Drop the per-core license
Kdb+ licensing scales with cores and runs into six and seven figures for serious research deployments. Arc is AGPL-3.0 with a commercial license that does not scale with cores. Research and backtesting move off the per-core meter without losing the analytical performance that work depends on.
Standard SQL onboards quants in days
A new quant who knows SQL is productive on Arc immediately. No q, no proprietary DSL, no six-week onboarding curve. The talent pool expands, and the time from hire to first useful query collapses.
Open Parquet, not a proprietary tick store
Your tick history lives as Parquet on storage you own. Every analytical tool can read it. If you ever move off Arc, your archive is intact and readable. The decade of history you accumulated is not trapped inside one vendor's format.
Microsecond resolution end to end
Microsecond timestamps are preserved through ingest, storage, and query. SQL window functions, time bucketing, and joins all operate at that resolution.
Real-time and historical in one store
Arc handles streaming ingestion of live ticks and analytical queries over years of history in the same database. Live market monitoring, intraday analytics, and full-history backtesting all run against the same Parquet, with the same SQL.
Why trading teams choose Arc over the alternatives
Kdb+ and q remain the incumbent for the execution hot path, and that is appropriate. For everything else, tick storage, backtesting, research, post-trade, compliance, the per-core license pays for capability you do not need. Arc handles all of it on standard SQL and open Parquet, at a fraction of the licensing cost.
Cloud data warehouses (Snowflake, BigQuery) were built for BI, not tick analytics. The cost of repeatedly running historical backtests across years of tick data on a warehouse is brutal and usually undisclosed until the quarter-end bill arrives. Arc keeps the data on your storage and removes the egress and per-query meter.
Timescale and Postgres extensions scale only so far before the write rate and cardinality of real tick volume becomes a problem. Arc was built for the volume.
ClickHouse is genuinely fast and operationally heavy. Arc is one binary instead of a cluster, with data in open Parquet rather than internal MergeTree.
Build-it-yourself DuckDB + Parquet is exactly what Arc is. DuckDB plus the streaming ingest, autonomous compaction, retention, replication, and operational layer a trading firm actually needs in production.
What this looks like in production
Arc is running in production analytical workloads today, including teams using it for tick storage, backtesting, and research outside the kdb+ hot path. Microsecond resolution preserved. Multi-year archives in open Parquet on customer-owned object storage.
AGPL-3.0 with a commercial license for organizations that need it.
Get started
See it run on financial data
Our live demos show real Arc workloads at scale.
Get Arc
Arc is open source and ships as a precompiled single binary. Pull it from the download page as Docker, Helm, or a .deb, point a tick feed at it, and start writing SQL. Source on GitHub.
Talk to us about your kdb+ bill
For research and backtesting workloads sitting on a per-core license, we run a discovery to scope what would move to Arc and what stays on the execution hot path.