Hello CrateDB Support Team,
We would like to report a difference in query behavior between CrateDB 5.10.16 and CrateDB 6.x when querying a partitioned table containing CLOSED partitions.
In CrateDB 5.10.16, queries spanning both OPEN and CLOSED partitions return data from the OPEN partitions while excluding the CLOSED partitions.
However, in CrateDB 6.2.8 and 6.4.5, we observed that a query spanning a CLOSED partition returns a count of 0, even when the query range also contains OPEN partitions with data.
We reproduced this behavior using a newly created test table in CrateDB 6.4.5.
Environment
• CrateDB versions: 5.10.16, 6.2.8, and 6.4.5
• Table type: Partitioned table
• Partition key: Generated TIMESTAMP column
• Query type: SELECT COUNT(*) with partition range conditions
Steps to Reproduce
Step 1: Create a test table
CREATE TABLE IF NOT EXISTS doc.test_closed_partition (
ts TIMESTAMP WITHOUT TIME ZONE,
pdate TIMESTAMP WITHOUT TIME ZONE
GENERATED ALWAYS AS date_trunc('day', ts)
)
PARTITIONED BY (pdate)
CLUSTERED INTO 1 SHARDS
WITH (number_of_replicas = 0);
Each daily partition contains two records, for a total of six records.
Step 3: Close the middle partition
ALTER TABLE doc.test_closed_partition
PARTITION (pdate = '2026-10-14')
CLOSE;
The partition states are now:
Partition State Records
2026-10-13 OPEN 2
2026-10-14 CLOSED 2
2026-10-15 OPEN 2
Step 4: Execute the following queries
Query A — Search only the OPEN partition on October 15:
SELECT COUNT(*)
FROM doc.test_closed_partition
WHERE pdate >= '2026-10-15'
AND pdate < '2026-10-16';
Query B — Search the entire range, including the CLOSED partition:
SELECT COUNT(*)
FROM doc.test_closed_partition
WHERE pdate >= '2026-10-13'
AND pdate < '2026-10-16';
Query C — Explicitly select only the two OPEN partitions:
SELECT COUNT(*)
FROM doc.test_closed_partition
WHERE pdate IN ('2026-10-13', '2026-10-15');
Test Results
Query CrateDB 5.10.16 CrateDB 6.4.5
Query A — OPEN partition only 2 2
Query B — Range including CLOSED partition 4 0
Query C — Explicit OPEN partitions 4 4
We also observed the same issue with range queries in CrateDB 6.2.8.
Expected Behavior
We expect Query B to return 4 records, excluding the CLOSED partition but including the records from both OPEN partitions, as observed in CrateDB 5.10.16.
Actual Behavior
In CrateDB 6.4.5, Query B returns 0 records.
However, Query A and Query C return the expected counts.
This indicates that the result depends on whether the query range includes a CLOSED partition, even though the OPEN partitions contain matching records.
The same behavior was observed in our production log table, which uses a generated daily partition key.
Questions
Could you please clarify the following?
Is this behavior an intentional change introduced in CrateDB 6.x, or is it a known issue?
If this is a known issue, is there an existing bug report or a version in which it has been fixed?
Is there any configuration setting or recommended workaround that allows range queries to skip CLOSED partitions while still returning data from OPEN partitions, as in CrateDB 5.10.16?
This behavior affects our log search functionality because historical partitions are periodically CLOSED, while users may search across date ranges containing both OPEN and CLOSED partitions.
We would appreciate your guidance on the expected behavior and any available resolution.
Thank you.
We are using the open-source edition of CrateDB without a commercial support subscription.
Since this behavior is reproducible on a newly created table and differs between CrateDB 5.10.16 and 6.4.5, we would appreciate confirmation from the development team as to whether this is an intentional behavior change or a regression.
If this is a bug, could you please let us know whether there is an existing GitHub issue or a planned fix?
Our development team reviewed the CrateDB source code and identified a potential issue in the partition routing logic, as shown in the attached screenshot.
We suspect this may be a regression introduced in CrateDB 6.x.
Could you please confirm whether this is a bug and whether a fix or improvement is planned for CrateDB 7.x?
We do not intend to modify the open-source code ourselves and would appreciate your feedback on whether this issue will be addressed in a future release.
Thank you for the detailed report and the clean reproduction. Looks like this is a regression, not an intentional change. Your team’s analysis is correct.
Could you open a bug report in Issues · crate/crate · GitHub ? That’s where the core team tracks and prioritizes server bugs, so the report won’t get lost, and you’ll be notified when it’s fixed. You may add this message link to bug issue.
