Make full applySeed execution bounded on D1

[oiwa-coder]

Summary

The latest released EmDash still performs enough sequential database work during a realistic fresh seed to exceed a bounded Cloudflare Worker subrequest budget, even though the wide-schema problem fixed by #2128 is already resolved.

I would like to contribute a measured optimization for the remaining applySeed() phases, starting with fresh content entries. Before writing it, I want to confirm whether maintainers prefer batching inside one setup request or a bounded, resumable seed protocol.

Reproduction and measurements

The seed is representative of a corporate site rather than a huge import:

• 22 collections
• 121 fields
• 92 content entries across those collections
• 1 taxonomy definition with 3 terms
• 2 menus
• 4 site settings
• no redirects, widgets, or sections

Using query instrumentation locally produced approximately:

Phase	SQL executions
Core migrations	363
Seed application	1,912
Total bootstrap	2,275

These measurements were captured from our deployed integration. Inspection of the latest released implementation confirms that the remaining content, taxonomy, menu, redirect, widget, and section phases still use the same sequential processing shape.

These are SQL executions, not yet a count of raw D1 binding calls or D1Database.batch() calls. A useful upstream regression should record both so that combining statements into one round trip is visible separately from reducing the statements themselves.

In a Workers for Platforms deployment where the authenticated bootstrap dispatch was bounded to 1,000 subrequests, two setup attempts failed after about 23–24 seconds with the generic SEED_ERROR. Raising the consumer-side limit is a workable short-term mitigation, but this amount of sequential work for 92 entries suggests there is still an upstream optimization opportunity.

Existing work I found

• fix(seed): bulk-create fresh collection schemas #2128 bulk-creates fresh collection schemas. It reduced a 74-field collection from 759 SQL executions to fewer than 50, and current releases already contain this fix.
• fix: reduce cold-start D1 queries from 159 to ~25 #532 reduced cold-start migration and initialization query volume.
• perf(cloudflare): opt-in coalescing of same-turn SELECTs into one D1 batch() round trip #1410 coalesces same-turn SELECT calls into one D1 batch() round trip.
• perf(core): batch cold-start init reads into one round trip #1617 batches the cold-start seed gate, plugin-state read, and site-info read.
• No way to bulk-import redirects #2291 independently documents that seeded redirects still perform sequential per-item round trips.
• fix(import): chunked, resumable WordPress plugin import (fixes Worker resource limits) #1849 provides a useful precedent for chunked, resumable work when an import cannot safely fit in one Worker invocation.

Those changes do not batch the seed mutations themselves. Current applySeed() still walks taxonomies, terms, bylines, content entries, menus, redirects, widgets, and sections through sequential loops. The content path performs per-entry existence checks and then repository operations for the entry, revisions, taxonomies, bylines, media usage, and publication state.

Related: explicit seed ownership

Discussion #1044 identifies a related problem for embedded EmDash installations: middleware auto-seeding can run before an embedder's explicit applySeed() call.

Our integration uses the bundled seed.json, so both passes use the same schema and do not cause the incorrect-schema failure described there. However, our authenticated bootstrap calls /_emdash/api/setup, whose handler explicitly applies the seed after runtime initialization may already have auto-seeded it. The second pass skips existing content instead of inserting it twice, but it still performs conflict lookups and leaves ownership of initialization ambiguous.

If applySeed() gains batching or resumable phases, embedded platforms also need a supported way to declare who owns initialization—for example, autoSeed: false. Otherwise middleware may begin a seed before the platform-owned bootstrap or recovery process does.

This is separable from the mutation-batching implementation, but the two contracts should be designed together: one owner should start the seed, and that owner should be able to execute it within bounded Worker invocations.

Proposed direction

Add a fresh-seed fast path with a query-count regression around a representative multi-collection seed:

1. Record SQL executions and D1 binding round trips by seed phase.
2. Prefetch existing content identifiers per collection instead of probing each entry separately.
3. Insert fresh content and related metadata in parameter-safe batches, while preserving generated IDs for references, menus, taxonomies, revisions, and media usage.
4. Preserve the existing onConflict behavior; keep the optimized path limited to cases where its semantics are unambiguous.
5. If a complete seed can still exceed a Worker invocation budget, expose bounded, idempotent phases/cursors using the same general approach as the resumable WordPress import.

I would start with content entries as one focused PR, with an explicit before/after ceiling, rather than attempting to rewrite every seed phase at once.

Questions

1. Would maintainers accept a PR focused on bulk-applying fresh content entries and their related records?
2. Should applySeed() remain a single-request operation, or should large seeds have a supported resumable/chunked execution path?
3. Should embedded integrations be able to disable middleware auto-seeding and make an explicit setup or applySeed() call the sole initialization owner, as proposed in Embedding API: opting out of middleware auto-seed #1044?
4. Is the existing query-count harness the preferred place for a seed-specific D1 round-trip regression, or should this live in the seed integration tests with a mock binding counter?