The InfluxDB 3 Core 72-hour query limit: what it is, why it exists, and your two ways out

Short version: InfluxDB 3 Core will not run a query that needs more than 432 Parquet files. At the default 10-minute file duration that is roughly 72 hours of data per query, sometimes less. It is a performance fence, not a retention rule: the older data is on disk and a narrower query reads it fine. You can raise the file cap with --query-file-limit, and the docs are upfront that you pay for that in query performance. The two real exits are designing around the window (downsample into rollups, query in slices) or moving long-range analytics to an engine built for it. Layerbase Cloud runs InfluxDB 3 Core with the upstream default, so the limit applies here exactly as it does on your laptop, and we also host QuestDB 10 for the workloads the window does not fit.

If you searched for this because a dashboard panel went blank the moment you widened it past three days, this post is for you. I run a database platform and this is one of the InfluxDB 3 questions we get most, so it seemed worth writing down properly rather than answering it one support ticket at a time.

What the limit actually is

InfluxDB 3 Core stores data as Parquet files on an object store, which in the single-node case is just a directory on disk. Every table gets its own files, and each file covers one block of time. The block size is the --gen1-duration setting (environment variable INFLUXDB3_GEN1_DURATION), which defaults to 10m and accepts 1m, 5m, or 10m. These are the "generation 1" files, and in Core they are the only generation there is.

When a query arrives, the planner works out which files it would need to read. If that number is higher than --query-file-limit (environment variable INFLUXDB3_QUERY_FILE_LIMIT), the query is refused. The default is 432.

Multiply the two defaults and you get the number in the title: 432 files at 10 minutes each is 4,320 minutes, which is 72 hours. The configuration reference puts it this way: with the defaults, "queries can access up to a 72 hours of data, but potentially less depending on whether all data for a given 10 minute block of time was ingested during the same period."

That second clause matters. The cap is on files, not hours. If late-arriving writes land in a 10-minute block after its first file was already written, that block has two files, and your 72 hours shrinks accordingly. Backfills are the usual way people find this out.

Everything I am quoting was read from that page on 2026-09-06. It is the kind of number that could change in a point release, so check it against the version you are running.

Why Core has it and Enterprise does not

The reason comes down to one missing component: a compactor.

A time-series database that writes small time-bounded files has to merge them eventually, or every long-range query becomes a scan across thousands of tiny files with all the open, seek, and footer-read overhead that implies. InfluxDB 3 Enterprise has that compactor. It merges gen1 files into larger generations, which is what the Enterprise docs mean when they list "historical query capability and single series indexing" as things Enterprise adds on top of Core, alongside high availability and read replicas.

Core does not compact. So instead of letting a query quietly read 20,000 files and take a minute to come back, it draws a line at 432 and refuses. InfluxData's own framing is that Core is for real-time and recent-data use cases, monitoring and dashboards that care about the last few hours, and the file cap is the mechanism that keeps those queries fast. I think that is a defensible design. It is just a surprise if nobody told you.

Worth saying plainly: the limit does not delete anything. Retention is a separate setting, per database, and data older than 72 hours is still on disk and still queryable as long as each individual query stays under the file cap.

What Layerbase runs

This is the fact the rest of the post turns on, so here it is without hedging.

Layerbase Cloud provisions InfluxDB 3 Core. The default version for a new database is 3.10, with 3.8 still supported for databases already on it. We start it with influxdb3 serve, with an admin token for authentication and a bearer token for your clients, and without any --query-file-limit override. The upstream default of 432 applies on Layerbase exactly as it does upstream. We do not run Enterprise, and we do not silently change the window.

I would rather you know that before you pick the engine than after your first four-day panel fails.

Check it yourself

Two requests tell you everything. First, confirm which edition and version you are talking to. On Layerbase the host and token come from the Quick Connect panel:

curl -s https://<host>.cloud.layerbase.dev/ping \
  -H "Authorization: Token $INFLUX_TOKEN"

{
  "product_name": "InfluxDB 3 Core",
  "version": "3.10.5",
  ...
}

Then run the same query twice with different ranges. Assume a table called http_requests that has been receiving writes every few seconds for a week:

# Two days: fine
curl -s "https://<host>.cloud.layerbase.dev/api/v3/query_sql" \
  -H "Authorization: Token $INFLUX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"db":"metrics","q":"SELECT count(*) FROM http_requests WHERE time >= now() - INTERVAL '\''2 days'\''"}'

# Four days: refused
curl -s "https://<host>.cloud.layerbase.dev/api/v3/query_sql" \
  -H "Authorization: Token $INFLUX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"db":"metrics","q":"SELECT count(*) FROM http_requests WHERE time >= now() - INTERVAL '\''4 days'\''"}'

The second one comes back as an error rather than a result. The exact wording depends on the version, so I am not going to quote one here; the reliable signal is a query error that mentions the file limit, and the server log has the full message including the count it hit. If the two-day query also fails, you have late-arriving writes splitting your blocks, and the window is narrower than 72 hours for that table.

You can reproduce all of this on your own machine before you plan around it. The Layerbase CLI runs the same Core binary locally with authentication off:

npm i -g layerbase
lbase create influx1 -e influxdb --start
lbase url influx1

Write a few days of backfilled points at 10-second intervals, run the four-day query, and watch it refuse. That is a ten-minute experiment that saves a bad architecture decision.

The knob, and what it costs

The documented workaround is to raise the cap:

influxdb3 serve --node-id node0 --object-store file --data-dir ./data \
  --query-file-limit 2000

Or the same thing as an environment variable, INFLUXDB3_QUERY_FILE_LIMIT=2000. On Layerbase Cloud the server flags are ours, not yours, so this knob is a local and self-hosted option rather than something you set from the dashboard.

The docs attach a cost to it in so many words: "Degraded query performance for queries that read more Parquet files." That is not a warning to ignore. A 2,000-file query is still 2,000 file opens, and there is no compaction coming along later to make it cheaper. Raising the limit turns a hard failure into a slow success, and whether that is an improvement depends on whether the slow query is on a dashboard someone refreshes every 30 seconds.

There is also a knob on the other side. Setting --gen1-duration 1m makes each file cover less time, which is good for very high write rates and bad for the window: 432 one-minute files is 7.2 hours. Do not touch gen1 duration to fix a query problem.

The pattern that works on Core

If you accept that Core is a recent-data engine, the design follows naturally and it is the same design monitoring stacks have used for twenty years.

Keep raw data for the window you actually inspect at full resolution. Set retention on the raw database to a few days. That is what the 72 hours is good at: fast queries over exactly the range an on-call engineer looks at.

Downsample into rollup tables on a schedule. A one-minute average of http_requests per endpoint is a few hundred rows a day instead of a few hundred thousand, which means a year of it fits in a handful of files and never comes near the cap. The InfluxDB getting-started guide walks through the three-tier layout, raw, hourly, and daily, with the retention commands for each.

Query in windows when you must scan raw data. A backfill job or a one-off investigation that needs a week of raw points can issue seven one-day queries and stitch them client-side. Ugly, but it works, and it is honest about what the engine is doing underneath.

If your workload is Telegraf feeding a Grafana wall and nobody looks past yesterday, this is not a compromise at all. It is the shape the product was built for.

The other exit: an engine built for long ranges

If the honest answer is that you need GROUP BY over 90 days of raw data, regularly, on a dashboard, then the file cap is not the problem. The engine choice is.

QuestDB is the time-series database we host next to InfluxDB, and it has no equivalent limit. It stores data in partitions rather than time-bounded files, it compacts on its own, and SAMPLE BY 1h over any range you like is one clause. It speaks the PostgreSQL wire protocol, so pg and psycopg2 and every SQL dashboard tool connect to it without an SDK. QuestDB vs InfluxDB is the long-form comparison with the same sensor pipeline built on both.

Two things to know before you jump. QuestDB's ingestion story is Influx Line Protocol or SQL INSERT, so a Telegraf pipeline moves over without rewriting the collectors. And QuestDB 10, which became the default on Layerbase this week, is a real major version with a few breaking changes for tooling that introspects the catalog. Read that post before you migrate an existing integration.

I should also be fair about the search results you probably arrived through. QuestDB published a benchmark on exactly this limit a while back, and it still ranks, and it is a vendor comparing itself favourably to a competitor. Read it as that. The limit is real; the conclusion that everyone should therefore switch engines is a sales conclusion. Plenty of workloads are better on InfluxDB 3, especially anything already built on Telegraf, line protocol, and per-database retention.

Pricing, since you will ask

Both engines are Performance engines on Layerbase: always on, never hibernated, no JVM or Rust cold start ahead of your first query of the morning. They run on the Pro plan, which also includes every other engine we host and 30-day backups. The pricing page has the current number. There is no per-query, per-series, or per-GB-scanned meter on either one, which is the part that matters when a dashboard refreshes every half minute.

FAQ

Does the 72-hour limit mean InfluxDB 3 Core deletes data after three days?

No. Retention and the query file limit are separate things. Retention is a per-database setting you choose. The file limit only caps how many Parquet files one query may read, and the default of 432 files at 10 minutes each works out to about 72 hours. Older data stays on disk and is queryable in narrower windows.

Why did my query fail at two days instead of three?

Because the cap counts files, not hours. When writes for a 10-minute block arrive after that block's first file has already been written, the block ends up with more than one file. Backfills and late-arriving data shrink the effective window. The server log shows the file count the query actually hit.

Can I raise the limit on Layerbase Cloud?

Not from the dashboard. Layerbase starts InfluxDB 3 Core with the upstream default of 432 and no override, so the limit here is the same as a fresh local install. Locally or self-hosted you can pass --query-file-limit or set INFLUXDB3_QUERY_FILE_LIMIT, with the documented cost of slower queries as the file count grows.

Does InfluxDB 3 Enterprise have the same limit?

Enterprise adds a compactor that merges gen1 files into larger generations, which is what the docs mean by "historical query capability." That is the mechanism that removes the practical ceiling. Layerbase does not run Enterprise; our InfluxDB databases are Core.

Is QuestDB a drop-in replacement?

For ingestion, close: QuestDB accepts Influx Line Protocol, so Telegraf and the line-protocol writers keep working. For queries, no: QuestDB is SQL over the PostgreSQL wire protocol, so InfluxQL queries and the @influxdata/influxdb3-client calls need rewriting. If your queries are already SQL, the rewrite is mostly swapping date_bin for SAMPLE BY.

Which should I pick for a new project?

If the workload is monitoring and the questions are about the last few hours or days, InfluxDB 3 with rollups is a good fit and the limit will never bother you. If the questions are about months of raw data on a regular basis, start on QuestDB and skip the workaround entirely. Both are a minute away on the same account.

Wrapping up

The InfluxDB 3 Core query file limit is a deliberate fence: 432 files per query, about 72 hours at the default 10-minute file duration, there because Core has no compactor to make long scans cheap. The knob exists and it is honestly documented as a trade. The durable answer is either to design for the window with rollups and retention, or to put long-range analytics on an engine with partitions and compaction.

Layerbase Cloud runs InfluxDB 3 Core at the upstream default and QuestDB 10 beside it. Create an InfluxDB database if your dashboards live in the last three days, or create a QuestDB database if they do not, and run the four-day query yourself before you decide.