I think the issue is likely not with your MySQL grants at all it's probably how Railway handles variables in PR environments.

When Railway spins up a PR environment, it clones your services but generates a brand new MySQL instance with a new password. Even though your app is using the same variable names linked to MySQL, I think what's happening is your DATABASE_URL or credentials aren't actually resolving to the PR environment's MySQL they might still be pointing to staging values.

Try this go into your PR environment, open the MySQL service and check the actual value of MYSQL_ROOT_PASSWORD, then compare it to what your app service is receiving. My guess is there's a mismatch there.

The fix is to make sure you're using Railway's internal reference syntax like ${{MySQL.MYSQL_URL}} instead of hardcoded values or copied variables that way Railway automatically resolves the correct credentials per environment, whether it's staging or a PR environment.

Hope that helps!

Oh yea that makes sense, thanks! However, I'd actually just like to share my primary staging database with all my PR environments. Is there a way I can do that? I guess I could use the public url??? But then each PR environment is just unnecessarily creating an unused DB service.

Glad that helped! For sharing your staging DB with PR environments, I think the simplest approach would be to just hardcode your staging database's public URL as DATABASE_URL at the PR environment level that way all PRs reuse it without spinning up a new instance.

To avoid the unused MySQL service being created at all, maybe try Railway's Focused PR Environments feature I think it only deploys services that are actually affected by the PR's file changes, so if your MySQL service isn't touched by the PR, it might get skipped automatically. Worth checking out in your project settings!

Just something to keep in mind though if any of your PRs run migrations they'd be hitting your real staging data, so might be worth adding a guard for that if it matters to you.