Tick Data Storage & Time-Series Databases

If you are one person running backtests, you do not need a database: write Parquet files and query them from DuckDB or ArcticDB, 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.

• SQL with an as-of join over Parquet files, no server — DuckDB.
• Versioned Pandas frames on S3, no server, no SQL — ArcticDB.
• A live feed writing while a dashboard reads — QuestDB.
• Scanning years of history fast, on commodity hardware — ClickHouse.
• You already run Postgres and want to keep it — TimescaleDB.
• A line-protocol or Telegraf pipeline already in place — InfluxDB 3.
• Sub-second aggregates for many concurrent users, not research joins — Apache Druid.
• The institutional standard, now with a free commercial tier — kdb+.
• kdb+'s shape — a vector language with aj — from another vendor, by quote — DolphinDB.
• The tick history bought together with the platform, by quote — OneTick.

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.

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 DuckDB 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. DuckDB reads a directory of Parquet files as a database before you have loaded anything; ArcticDB adds a version chain and a symbol catalogue on S3. QuestDB, ClickHouse, TimescaleDB, InfluxDB 3, kdb+, DolphinDB, OneTick and Druid are servers, and a server is a thing you operate for as long as you use it — Druid most of all, at six process types plus deep storage, a metadata database and ZooKeeper.

The rough rule: one person running backtests wants a library; a live feed writing continuously while a dashboard reads wants a server. The library side has a hard edge — in DuckDB one process writes and any other can attach only read-only, and in ArcticDB two writers to one symbol are last-writer-wins. 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.

Druid is the clearest case of an engine built for the second shape: a query path designed so that a dashboard with a hundred users on it still answers in well under a second, and documentation that names high insertion rates and aggregation-heavy queries as the fit. It expects to roll rows up into a chosen granularity at ingest, so keeping raw prints means switching off the feature the engine is built around, and its joins are broadcast, with everything but the leftmost datasource held in memory. InfluxDB 3 Core shows the opposite pressure: it writes fast, but with no compactor its small Parquet files are never merged, and by default a single query reads roughly 72 hours of them.

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, QuestDB and DuckDB have ASOF JOIN as a keyword; kdb+ has aj and DolphinDB has aj and wj as functions in a vector language closer to q than to SQL, with a streaming as-of join engine that runs the same logic over live ticks. QuestDB adds LT JOIN for the strictly-earlier match and a TOLERANCE clause that rejects a stale quote. Druid and InfluxDB 3 have no as-of operator at all — InfluxDB's SQL documents the four standard joins and nothing else — and anything Postgres-based means a LATERAL subquery per row. OneTick's queries are graphs of the vendor's own event processors, transaction-cost analytics among them, and the same graph runs unchanged over history or a live feed.
• Bar aggregation, ticks to OHLCV at an arbitrary interval. SAMPLE BY in QuestDB, time_bucket with continuous aggregates in TimescaleDB, time_bucket in DuckDB, a materialized view into AggregatingMergeTree in ClickHouse, rollup at ingest in Druid, and Python triggers inside the database on write or on a schedule in InfluxDB 3. They differ enormously in whether the result is maintained incrementally as ticks arrive or recomputed.
• Late and out-of-order ticks, which arrive in every real feed. QuestDB merges out-of-order rows into place on ingest; ClickHouse inserts a late print but does not recompute a bar already materialized; Druid's segments are immutable, so a correction is a re-ingestion of the interval; DuckDB has no ingest path at all — rows arrive when your own code runs INSERT or COPY. 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

Five of the ten carry an OSI licence on at least their core build, one splits its features between Apache-2.0 and a vendor licence, one is BSL, and three — kdb+, DolphinDB and OneTick — are closed. 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, DuckDB is MIT with no enterprise edition of any kind, and Apache Druid is Apache-2.0 under a foundation that sells nothing. DuckDB's company joined AWS in 2026; the intellectual property stays with the non-profit DuckDB Foundation and the licence did not change. Managed DuckDB and managed Druid come from separate companies, MotherDuck and Imply, not from the projects.

Open core. QuestDB's server is Apache-2.0 and complete enough to run in production; replication with failover, TLS, SSO and role-based access with audit logs, and tiered storage are QuestDB Enterprise, which is proprietary and quoted. InfluxDB 3 Core is MIT or Apache-2.0 with real caps — 5 databases, 2,000 tables, 500 columns per table, one node, no compactor — and compaction and clustering are in Enterprise, sold per CPU core with no published price; its free at-home Enterprise licence bars commercial use. 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 and modifying it are free. The company has traded as Tiger Data since June 2025 and the managed service is now Tiger Cloud, while the extension kept the name TimescaleDB, so the same terms now appear under two names.

Business Source License 1.1. ArcticDB's licence text forbids exactly one thing — offering it as a database service — and converts each released version to Apache-2.0 two years after that version shipped, so 4.5 and everything before it are Apache-2.0 and 5.0 converts on 31 October 2026, while the current release is 6.25.0. Read the vendor's README and licensing FAQ alongside the file, though, because they assert something broader than the licence text does: the README that production use needs an agreement, the FAQ that any business use, research and development environments included, requires a commercial licence. Those documents do not say the same thing, and if you are a company the FAQ is the one your counsel will find.

Proprietary. Three engines here are closed, and each draws the free line differently.

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, 4 secondary threads and 16 connections per process. That is a genuine change: the older kdb+ Personal Edition, which did not permit commercial use, now redirects to it. Above the cap KX publishes a price list by memory, from $1,822.92 a month at 32 GiB to $11,437.50 at 127 GiB; from 128 GiB, and for a classic kdb+ licence, it is a quote.

DolphinDB's server is a closed binary — the open-source repositories are its clients — with a free perpetual community licence capped at 2 nodes, 2 CPU cores and 8 GB of RAM per node, which is a development licence rather than a production one. Above it no price is published anywhere.

OneTick has no free tier and no community edition, and no price for either the platform or OneTick Cloud; the route is a demo, a trial and a contract. Its vendor merged with KX on 15 September 2025, so it is now sold beside kdb+ by the same company, though the OneMarketData name survives in legal and package metadata.

What it costs

Most of this is free to run and none of it is free to operate. The direct bills are hosted tiers priced by compute and storage, where you are paying to not run the server yourself — ClickHouse Cloud, Tiger Cloud, InfluxDB Cloud, and Imply and MotherDuck for Druid and DuckDB — plus kdb+'s published memory ladder above 16 GB, and quotes for QuestDB and InfluxDB Enterprise, DolphinDB above its capped community licence, and OneTick at any size. 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. OneTick Cloud is the one product here that sells ticks with the engine — trades and quotes back to 1993 across more than 200 markets, on the vendor's count — and what its subscription covers in exchange fees is a contract term. Every other engine holds what you already have a right to; where that right comes from is settled in market data APIs, and the read pattern you are optimising for is usually decided in backtesting frameworks.