The Medusa quickstart is genuinely good at what it's for: a working storefront backend in minutes, running on SQLite in a single process. It's also not close to what a production deployment needs, and treating it as a starting point for production without rethinking several defaults is where most deployment pain comes from.
Split server and worker mode
Medusa supports running as a single combined process or as separate server and worker processes, and production deployments should use the split. The server process handles API requests; the worker process handles background jobs and scheduled tasks. Splitting them means a slow or misbehaving background job, a bulk import, a heavy scheduled sync, can't degrade storefront response times, and each can be scaled independently based on its own load pattern rather than one shared instance count.
Postgres, not SQLite, and Redis for the event bus
SQLite is fine for local development and genuinely wrong for production: no real concurrent-write story, no separate database server to back up and monitor independently of the application. Postgres is the only realistic production choice. Redis sits alongside it, backing Medusa's workflow engine, event bus, and distributed locking, functionality that falls back to in-memory implementations without Redis, implementations that don't survive a restart and don't work correctly once you're running more than one server instance.
Migrations as a deliberate deployment step
Schema migrations deserve their own attention, not a silent "runs automatically on deploy" default. On a table with real production data, a migration that looks trivial in a local database with a few hundred rows can lock a much larger table for long enough to matter during business hours. Review what a migration actually does to table locks at your real data volume before it runs against production, and have an explicit rollback plan for a migration that fails partway through, not just a hope that it won't.
Moving a Medusa backend from local dev toward a real production deployment?
Tell us where you are today. We'll tell you honestly which of these gaps actually matter for your traffic and timeline, and which can wait.
Talk to an engineer →A backup plan you've actually tested
A backup that's never been restored is a hope, not a backup plan. Automated Postgres backups are table stakes; the part teams skip is periodically actually restoring one to a scratch environment and confirming the data comes back correctly and the application boots against it. The first time you test a restore process should not be during a real incident.
| Kryeo | Quickstart / local dev | |
|---|---|---|
| Database | Postgres, backed up and tested | SQLite, single file |
| Process model | Server and worker split | Combined single process |
| Event bus / locking | Redis-backed | In-memory, doesn't survive restart |
| Migrations | Reviewed for lock behavior, deliberate step | Runs automatically alongside code |
The rule
Treat the quickstart as proof the application works, not as a production architecture. Split server and worker processes, move to Postgres and Redis, review every migration for its actual lock behavior at your data scale, and test your restore process before you need it for real. For how this infrastructure scales further once real traffic arrives, see architecting a Medusa backend for a traffic spike you haven't seen yet. We handle deployments like this under Medusa development engagements.