# Handling large partition and full scan query when operating ScyllaDB

**URL:** <https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956>\
**Category:** ScyllaDB\
**Tags:** data-model, performance, large-partitions\
**Created:** [July 5, 2025, 1:32am UTC](https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956 "2025-07-05T01:32:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![qrlagusdn](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/qrlagusdn/32/1756_2.png) [@qrlagusdn](https://forum.scylladb.com/u/qrlagusdn)\
**Post date:** [July 5, 2025, 1:32am UTC](https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956/1 "2025-07-05T01:32:55Z")

</div>

_Installation details_  
#ScyllaDB version: 5.4  
#Cluster size: 3 each DC1,2  
#os (RHEL/CentOS/Ubuntu/AWS AMI): CentOS

Hi all — I’m using **ScyllaDB** to store transactional data and had a few questions around query patterns and cluster impact.

- We need to fetch **1-day range of data** , which can be hundreds of thousands of rows.
- There’s a chance of **large partitions.** Very few. Some 0.001% user have about 630k trasactions.
- A single query timing out is okay — **but we must avoid impacting other services** due to one heavy scan.

So far I’m thinking:

- **Bucketing** to reduce hot partitions, but read burden may still be high.
- **LIMIT** doesn’t help much if hot partition happens anyway.
- **Pagination** could help — but unclear if it prevents cross-service impact.
- Maybe **Materialized Views**?

I’d love to hear your experience on:

- How do you **monitor or alert** for large partition reads in production?
- How do you **prevent** the Full scan query like Count query and large partition query?
- What strategies do you use to **contain the impact** of large queries — whether at the app level or through cluster tuning (e.g., read concurrency, timeouts, coordinator limits)?

Has anyone tackled similar patterns or have suggestions from an app-level or cluster tuning perspective?  
Thanks a lot!

---

<div class="post-metadata">

**Author:** ![Botond\_Denes](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/botond_denes/32/163_2.png) [@Botond\_Denes](https://forum.scylladb.com/u/Botond_Denes)\
**Post date:** [July 15, 2025, 10:39am UTC](https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956/2 "2025-07-15T10:39:50Z")

</div>

Look into [Workload Priotization](https://docs.scylladb.com/manual/stable/features/workload-prioritization.html), it was designed exactly for this use-case: isolate heavy but non-latency sensitive scans from other queries.

---

<div class="post-metadata">

**Author:** ![qrlagusdn](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/qrlagusdn/32/1756_2.png) [@qrlagusdn](https://forum.scylladb.com/u/qrlagusdn)\
**Post date:** [July 16, 2025, 9:16am UTC](https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956/3 "2025-07-16T09:16:14Z")

</div>

Thank you for the reply!  
Just to confirm, isn’t Workload Prioritization an enterprise-only feature?

---

<div class="post-metadata">

**Author:** ![Botond\_Denes](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/botond_denes/32/163_2.png) [@Botond\_Denes](https://forum.scylladb.com/u/Botond_Denes)\
**Post date:** [July 16, 2025, 10:38am UTC](https://forum.scylladb.com/t/handling-large-partition-and-full-scan-query-when-operating-scylladb/4956/4 "2025-07-16T10:38:32Z")

</div>

With the [move to source-available](https://www.scylladb.com/2024/12/18/why-were-moving-to-a-source-available-license/), we no longer have enterprise-only features. All features are available in the single source-available release stream.