Does omitting the 'last' cursor in Deta Base fetch operations produce latency spikes that mimic connection pool exhaustion?

Direct answer

Yes. Omitting the last cursor forces the SDK to restart each fetch from the beginning of the base, producing full scans whose latency grows superlinearly with base cardinality. On Deta Space, these long-running scans consume per-instance request quotas and wall-clock time, generating timeouts and 429/5xx responses that are indistinguishable from connection-pool exhaustion without additional instrumentation.

Likely explanation vs. confirmed facts

Confirmed (from SDK behavior and platform quotas)

• Deta Base pagination is cursor-based; without last the SDK issues a new scan from the first item on every call.
• Scan latency grows with the number of items scanned — item size limits and internal pagination mean a 100k-item base can take seconds per fetch.
• Deta Space Micros enforce per-instance request-duration and concurrency quotas; long scans eat quota and trigger platform throttling (HTTP 429, request termination).
• The SDK does not expose underlying HTTP connection lifecycle, so client-side logs show only elapsed time and generic timeout errors.

Likely but not universally verified

• Latency spikes correlate with base size and fetch frequency, not with concurrent connection count.
• Newer SDK versions may change default cursor handling (e.g., implicit cursor reuse); behavior can differ across Deta Space runtime releases.
• Network jitter and concurrent user load can amplify or mask the pattern.

Steps to isolate the cause in your deployment

1. Add request-id and duration logging around every fetch() call. Record whether last was supplied, the returned cursor, and wall-clock time.
2. Run two controlled loops against a static base snapshot: one with last cursor chaining, one without. Keep batch size identical.
3. Compare timeout rates and error codes between the two runs. Cursor-omitted loops should show higher p95 latency and more 429/5xx responses as base size grows.
4. Check the Deta Space dashboard for per-instance request-quota utilization during the tests. Quota saturation concurrent with long scans confirms platform throttling rather than client-side connection limits.

One missing diagnostic that changes the recommendation

What is the typical base cardinality and average item size in the affected micros? If the base is under ~5k items and items are small (<1 KB), scan latency may be low enough that quota exhaustion is unlikely; in that case, investigate SDK retry logic or external network latency first. If the base exceeds 10k items or items approach the 1 MB limit, cursor omission is the primary suspect and the steps above will confirm it.