The Goal & The Challenge

Our target for Public Preview is to fully support 250k tables in DSC. Because one table requires four data handles, we are effectively targeting a massive scale of 1 million data handles.

Right now, our visibility into how the system behaves at this scale is limited. We currently rely on a single "startup perf test" to hit the 250k limit, while (data_handle_locust) only tests up to 20k tables. Crucially, we do not have any tests evaluating the system with 250k data handles over a sustained period of time.

The Current Situation
Based on the limited test data we do have, we are hitting a wall in two distinct categories:

1. Stability: When pushing toward the 250k limit, we start hitting severe stability issues (OOM and OS file-descriptor limit) well before reaching the target.
2. Performance: The table creation process in DSC takes significantly longer compared to ASC. – WT-17617

The Discovery Ask
The purpose of this ticket is to step back and formulate a structured problem statement. Before we move to fixes, we need to do an investigation into both the stability and performance bottlenecks to clearly define what is actually breaking and why.

Specifically, this discovery phase must answer three core questions:

• What is our true stability baseline? Exactly how many tables/data handles can we safely create before seeing stability issues?
• What is the true performance gap? What is the precise performance comparison (latency delta) between ASC and DSC when creating up to 250k tables?
• Is our current testing sufficient? Do our existing tests give us enough visibility to safely debug and reach this scale, or do we need to build new, longer-running tests to build confidence?

In-Flight Context

Note: Some early work has already started to address known bottlenecks. This discovery effort should align with, but not duplicate, the following tickets:

• WT-17323: Updating the sweep server to close idle ingest tables post-checkpoint (targeting stability/OOM).
• WT-17617: Investigating the ASC vs. DSC table creation latency delta (targeting performance).

Expected Deliverables

To close this ticket, the assignee will provide:

1. A Categorized Problem Definition: A clear breakdown of the exact stability and performance failures we are hitting at scale.
2. A Testing Strategy: A definitive answer on whether we need to expand our current testing footprint to build confidence for Public Preview.
3. Product Communication Brief: Documented numbers on the maximum safe table limit and the ASC vs. DSC latency gap.