When should I move my game from SQLite to PostgreSQL?

The main reasons to move away from SQLite usually aren’t raw request counts. Consider migrating when you need multiple application servers writing to the same database, when concurrent writes become a bottleneck, or when your hosting setup uses temporary storage that could erase the database during a redeploy. Enabling WAL mode can also improve SQLite’s behavior for many workloads. Using SQLAlchemy and a proper migration tool now will make a future move to PostgreSQL much easier.

A useful middle ground is to add a data-access layer now. Keep database queries and persistence logic in one part of the application instead of scattering SQL throughout the code. Then your game code works with normal objects or service methods, making it much easier to switch database engines later. PostgreSQL would be a sensible destination if you eventually need one.

Set up observability before making a major infrastructure change. Track response times, error rates, database-lock errors, query duration, disk usage, and request volume. If a metric stays above a threshold, investigate and profile the actual bottleneck before changing the stack. Refactor when the expected benefit justifies the implementation and maintenance cost, not simply because the project has grown.

SQLite can absolutely be used in production, especially for a small application. If the app is handling your current traffic comfortably, there’s no need to migrate just because PostgreSQL is more commonly associated with production. Waiting until you have a concrete need is reasonable.

I usually start projects with PostgreSQL in a Docker container because it keeps local development closer to the eventual production environment. That’s mostly a workflow preference, though—not proof that SQLite is unsuitable. For a small game, SQLite may be perfectly adequate.