# Tick Data Storage & Time-Series Databases

Where a year of ticks lives — an embedded library or a server you operate, the three queries this domain runs, and the licence on each.

*https://stockmarketstack.com/categories/tick-data-storage*

If you are one person running backtests, you do not need a database: write Parquet files and query
them from ArcticDB or an embedded engine, and skip the operating cost entirely. You need a server
when something writes a live feed continuously while something else reads it, or when the data
outgrows the machine — and at that point the question is which of three queries you run most.
Everything below is that decision in detail.

- **Python research, no server, no ops** — [ArcticDB](https://stockmarketstack.com/tools/arcticdb).
- **A live feed writing while a dashboard reads** — [QuestDB](https://stockmarketstack.com/tools/questdb).
- **Scanning years of history fast, on commodity hardware** — [ClickHouse](https://stockmarketstack.com/tools/clickhouse).
- **You already run Postgres and want to keep it** — [TimescaleDB](https://stockmarketstack.com/tools/timescaledb).
- **The institutional standard, now with a free commercial tier** — [kdb+](https://stockmarketstack.com/tools/kdb).

The other half of what people call developer infrastructure — what actually draws the candles in a
product you ship — is a separate shopping trip with no shared vendor, price model or unit of
comparison, and it lives in [charting libraries](https://stockmarketstack.com/categories/charting-libraries).

## A server you run, or a library that writes files

This is the deepest division in the group and it is not a feature difference. ArcticDB, and
Parquet queried by an embedded engine, run inside your own process and write to local disk or
object storage: no daemon, no port, no user accounts, no failover plan, nothing to patch. QuestDB,
ClickHouse, TimescaleDB and kdb+ are servers, and a server is a thing you operate for as long as
you use it.

The rough rule: one person running backtests wants a library; a live feed writing continuously
while a dashboard reads wants a server. Choose the library until something forces the server,
because the forcing event is obvious when it arrives and the ops bill is not.

## Ingest and query pull in opposite directions

A backtester reads one symbol-year sequentially, once, and wants raw scan speed over cold data. A
dashboard reads the last few hundred points for fifty symbols, repeatedly, concurrently, and wants
the newest rows to be instantly visible. An engine tuned for one is mediocre at the other, and
vendor benchmarks always publish the side that flatters them. Decide which of the two shapes your
load actually is before you read a number.

## Ask how it does the three queries this domain runs

Not how fast it is in general.

- *As-of joins*, described in the FAQ below. ClickHouse and QuestDB have the keyword; kdb+ has `aj`
  and has had it for decades; anything Postgres-based has no such operator and you write a LATERAL
  subquery per row. QuestDB added `HORIZON JOIN` in early 2026 specifically for markout analysis,
  which is the same idea pointed forwards in time.
- *Bar aggregation*, ticks to OHLCV at an arbitrary interval. `SAMPLE BY` in QuestDB,
  `time_bucket` with continuous aggregates in TimescaleDB, `xbar` in kdb+, interval functions plus
  aggregate combinators in ClickHouse. All of them work; they differ enormously in whether the
  result can be maintained incrementally rather than recomputed.
- *Late and out-of-order ticks*, which arrive in every real feed. Some engines absorb them as a
  normal write, some rewrite a partition to do it, and some make you re-sort before load. This is
  the detail that decides whether your ingest pipeline is ten lines or a project.

## Footprint after compression, measured on your data

Compression ratios quoted by vendors come from machine telemetry — low-cardinality, slowly
varying, extremely compressible. Market data is not that, and how well it packs depends on whether
you keep quotes or only trades and on how many symbols you carry. Load one month of your own
ticks, look at the bytes on disk, then multiply. Nobody's published ratio survives that test
unchanged.

## The licence words, and what each one actually permits

Every product here is described by somebody as open source, two are not, and more than one has
changed terms since 2023. Read the LICENSE file of the version you pin, not the badge in the
README.

**OSI open source** — no conditions on what you build or sell. ClickHouse is Apache-2.0, and so is
QuestDB's core.

**Open core.** QuestDB's server is Apache-2.0 and complete enough to run in production; high
availability with failover, SSO and role-based access with audit logs, and tiered storage are
QuestDB Enterprise, which is proprietary and quoted. Nothing is crippled — but the features you
will want the day this becomes someone else's production system are the paid ones.

**Source-available under a vendor licence.** TimescaleDB's Apache-2.0 core is a small part of it:
Hypercore compression, continuous aggregates, retention policies, hyperfunctions and SkipScan are
under the Timescale License, which is not an OSI licence and forbids offering the software as a
service. Self-hosting it for your own use, commercial use included, is free and always has been.
The company renamed itself TigerData in June 2025, so the same terms now appear under two names.

**Business Source License 1.1.** ArcticDB's licence text forbids exactly one thing — running it as
a database service for third parties — and converts each released version to Apache-2.0 two years
after that version shipped, so 4.5 became Apache-2.0 in August 2026 and 5.0 does at the end of
October. Read Man Group's licensing FAQ alongside the file, though, because it asserts something
broader than the licence text does: that any business use of a BSL version, research and
development environments included, requires a commercial agreement. Those two documents do not say
the same thing, and if you are a company the FAQ is the one your counsel will find.

**Proprietary with a capped free tier that now allows commercial use.** KX announced KDB-X
Community Edition in November 2025 — free for personal *and* commercial projects, limited to 16 GB
of RAM for the q process, one physical or virtual instance, and 4 secondary threads. That is a
genuine change: the older kdb+ Personal Edition is non-commercial only, tied to your own machines
and barred from the cloud. Paid kdb+ remains quote-only, and pricing that circulates in forums is
hearsay.

## What it costs

Most of this is free to run and none of it is free to operate. The direct bills are small and easy
to find: hosted tiers priced by compute and storage, where you are paying to not run the server
yourself, and a quote for the two proprietary options. Everything else is your time — schema
design, the ingest pipeline, backfills, the upgrade you put off.

And the data itself, which will cost more than any of it. A storage engine holds what you already
have a right to; where that right comes from is settled in
[market data APIs](https://stockmarketstack.com/categories/market-data-apis), and the read pattern you are optimising for is
usually decided in [backtesting frameworks](https://stockmarketstack.com/categories/backtesting-frameworks).

## Cards

- [ArcticDB](https://stockmarketstack.com/tools/arcticdb.md) — Versioned Pandas frames written straight onto S3, with no server to run.
- [ClickHouse](https://stockmarketstack.com/tools/clickhouse.md) — Columnar OLAP database that keeps years of ticks on disk cheaply and scans them fast.
- [DolphinDB](https://stockmarketstack.com/tools/dolphindb.md) — Closed-source tick database with a vector language, as-of joins and streaming engines.
- [Apache Druid](https://stockmarketstack.com/tools/druid.md) — Real-time OLAP cluster built for high-concurrency dashboards, not for research joins.
- [DuckDB](https://stockmarketstack.com/tools/duckdb.md) — In-process analytical SQL over Parquet tick files, with no server to run.
- [InfluxDB 3](https://stockmarketstack.com/tools/influxdb.md) — Line-protocol time-series database rewritten on Arrow, DataFusion and Parquet.
- [kdb+](https://stockmarketstack.com/tools/kdb.md) — The tick database trading desks have run for 25 years, queried in q rather than SQL.
- [OneTick](https://stockmarketstack.com/tools/onetick.md) — Enterprise tick capture, storage and streaming analytics, sold only by quote.
- [QuestDB](https://stockmarketstack.com/tools/questdb.md) — Open-source time-series SQL built for tick data — ASOF JOIN, SAMPLE BY, LATEST ON.
- [TimescaleDB](https://stockmarketstack.com/tools/timescaledb.md) — Hypertables, columnar compression and continuous aggregates bolted onto plain Postgres.

## FAQ

### Do I need a time-series database to store tick data?

Not if you are one person doing research. Years of daily and minute bars fit in Parquet files on a laptop and query fast from an embedded engine or a DataFrame library, with no server to run. A database server starts earning its keep when something writes continuously while something else reads, when more than one process queries at once, or when the data outgrows the machine.

### What is an as-of join and why does every tick-storage comparison mention it?

It matches each row in one time series to the most recent row in another at or before that instant — every trade to the quote in force when it printed, every signal to the last bar before it. It is the query this domain runs constantly and the one a general-purpose database does worst. ClickHouse and QuestDB both have an ASOF JOIN keyword, kdb+ has aj, and on Postgres you write it yourself as a LATERAL subquery.

### Is kdb+ still the only serious choice for tick data?

No, and it has not been for several years. ClickHouse and QuestDB run the same as-of joins and bar aggregations in SQL on commodity hardware, and ArcticDB covers the Python research case with no server at all. KX's own answer to that was KDB-X Community Edition in November 2025 — free for commercial use, capped at 16 GB of RAM and a single instance.

### Which tick-data stores are genuinely open source?

ClickHouse and QuestDB's core carry OSI licences. ArcticDB is Business Source License 1.1, where each release turns Apache-2.0 two years after it shipped. TimescaleDB's compression, continuous aggregates and hyperfunctions are under the source-available Timescale License, not the Apache-2.0 core. kdb+ is proprietary with a capped free edition.

### How much disk does a year of US equity tick data need?

Nobody's published compression ratio answers this, because the quoted ones come from machine telemetry — low-cardinality, slowly varying, extremely compressible — and market data is not that. Whether you keep quotes or only trades changes the answer by an order of magnitude, and so does the number of symbols. Load one month of your own ticks, measure the bytes on disk, then multiply.