nuzlocke-tracker/.beans/nuzlocke-tracker-spx3--evaluate-separate-seedinit-container-after-pokedb.md

title, status, type, priority, created_at, updated_at

title	status	type	priority	created_at	updated_at
Evaluate separate seed/init container after PokeDB import	scrapped	task	low	2026-02-10T14:30:57Z	2026-02-11T20:15:43Z

After the PokeDB.org data import (beans-bs05) is complete, evaluate whether the seed data has grown enough to justify splitting seeding into a separate init container.

Context

• Backend container is currently 76 MB; seed JSON data is ~5 MB
• After PokeDB import, seed data may grow significantly (filling in Gen 8+, Let's Go, etc.)
• The seed runner is tightly coupled to backend models/DB — a fully separate container isn't practical
• The pragmatic pattern: same backend image, different entrypoint as a one-shot init service in Docker Compose

Approach (if we proceed)

• Add a seed service to docker-compose.prod.yml using the same API image
• Move alembic upgrade head + python -m app.seeds into the seed service command
• Use restart: "no" and service_completed_successfully dependency
• API service depends on seed completing before starting
• API command becomes just uvicorn ... — no migrations or seeding

Decision criteria

• Measure the final seed data size after PokeDB import
• If seed data exceeds ~15-20% of image size, the split is worthwhile
• Even below that threshold, the separation of concerns (migrations/seeds vs serving) may justify it

Additional benefits

• Failure isolation: seed failure prevents API startup cleanly
• Idempotency: seed runs once per deploy, API can restart freely
• Cleaner API startup path