I have never used Snyk, but I've used similar tools.
Running a scan on every pull request seems unnecessary unless that pull request is introducing a change to your dependencies. From my understanding of Snyk's documentation, Snyk scans your manifest files and uploads the dependencies and their versions. As Snyk's database of vulnerabilities is updated, it will alert you of any newly discovered or reported vulnerabilities in your dependencies. Unless you are adding, removing, or updating a dependency, you don't need to rescan.
The first question I would consider is how frequently you are changing your dependencies. If you are regularly changing your dependencies, then you may need to more regularly scan and upload the information from your manifest files to Snyk to make sure the reporting is accurate. However, if you don't change your dependencies often, then there may not be a need to scan as often. If the bottleneck is how long it takes to run a scan and upload the results to Snyk, I'm not sure that this action needs to be taken on every pull request.
If you really wanted the most accurate information, you could introduce some kind of logic to your build server to detect changes to your manifest files and execute a Snyk scan only on pull requests that introduce a change to your manifest file.
The more important thing, in my opinion, is how often you review the results from Snyk. It appears that Snyk does offer push notifications via email, Slack, and other tools when a dependency in your project has a vulnerability. This push notification could be useful to trigger your triage process to determine your exposure to the vulnerability and understand what you need to do to mitigate it.
If you've introduced Snyk to an existing project that has a lot of dependencies, you may be in a mode to play catch-up with updating to patch existing vulnerabilities. Rescanning on every pull request won't really help here, though, unless you're making lots of small pull requests to update each dependency and want Snyk to detect the change. I'm not sure that this is a good approach, though. I'd favor making sure that you have good automated test coverage, updating your dependencies, making any changes to your code to account for the new dependencies, and running both automated and manual testing to confirm that your changes are good. This is a good tactic if you have a large number of very out-of-date dependencies and are pulling major updates in - there could be a lot of work necessary to replace dependencies and it could be worthy of a release of its own.
Having a more robust process to control when dependencies are added and ensuring those dependencies are either free of vulnerabilities, the vulnerabilities are mitigated, or the vulnerability doesn't impact your system is also necessary. This doesn't necessarily require the use of Snyk. There are databases of open-source projects and their vulnerabilities - Snyk maintains one, as does Synopsis. Performing a lightweight vendor assessment to ensure that new dependencies do not introduce new vulnerabilities and you are only introducing dependencies that are well-maintained and offer an acceptable level of support is a good habit to get into.
After all of this, I would favor a nightly or weekly scan. On the more complex systems that I've worked on, running the full suite of all tests (from unit to system acceptance) takes a couple of hours. This testing happens on the development branch on a nightly basis. Integrating an open-source dependency scanner here can make sure that your reporting is always up-to-date, without introducing an extra step into every build. Developers can check in on the build every morning and triage failing tests as well as triage new vulnerabilities in dependencies. This can also be a good time to run static analysis on your code, and if you want to get very secure, deploy to a test environment and run dynamic vulnerability scanners.