Replit DB – query bounding and pagination: missing server‑side limit support

Direct answer

Replit DB's iterator() does not support server-side limit, offset, or filter parameters. Every enumeration traverses the complete keyspace. In this context there is no public roadmap confirming when, or if, such query-bounding features will be added.

Confirmed behavior vs. likely explanation

Confirmed: The iterator exposes all stored keys with no built-in pagination controls. Likely: Enumeration cost scales linearly with key count, which becomes painful as a collection approaches the 1 MB storage ceiling. Uncertain: Any future API additions, exact latency thresholds, or undocumented parameters. Treat roadmap speculation as unverified.

What server-side bounding would and would not change

If Replit later adds limit or offset, it would reduce the number of keys transferred and parsed per request, lowering latency and memory pressure during pagination. It would not raise the 1 MB storage cap, which is a separate capacity boundary. Until then, the storage limit remains the hard constraint on total dataset size.

Recommended pattern today

1. Measure first. Time an iterator() pass over your actual key count to confirm whether linear scaling is a practical bottleneck in your Repl.
2. Small datasets: Use client-side slicing. Fetch the keys once, slice in application code, and cache the result for read-heavy workloads.
3. Large datasets: Maintain a custom index. Store a separate key—for example, a bucketed prefix scheme or a JSON array of record IDs—so you can retrieve a bounded page without scanning every key.

Practical verification

Before committing to an indexing strategy, measure enumeration time in your own environment. A safe, scoped check is to iterate over the keys, count them, and log the elapsed time. If the operation completes quickly at your current scale, client-side pagination is acceptable. If it is already slow, invest in a custom index. Also inspect the current Replit DB documentation or console metadata for any newly introduced query parameters, since the API surface may evolve.

One diagnostic detail that changes the advice

What is your approximate key count and average value size? If you are well under a few hundred keys, client-side slicing is fine. If you are nearing the 1 MB limit with thousands of keys, build a custom index instead.