ValhallaThere's clearly some misunderstanding going on, the API already has a throttling system to limit traffic and prevent abuse, this is what should be tweaked if needed.
The bug doesn't prevent us from requesting more than 10k results at once since that was always impossible, requests are limited to a maximum of 200 results. What it prevents is accessing results with an offset of >=10k.
This means that if I want to do something as simple as graph the number of runs submitted over time of a popular game I can't because there's no straightforward way to obtain every run of that game (even if I request 200 runs every 30 minutes).
If the database is somehow actually dying from reading past 10k rows for the rate-limitted API users then enable cursor-based pagination (which every framework supports) instead of silently breaking the API
The recent "performance improvement" changes to the site have broken the API and nobody seems to care. I'm posting here since the issue on the GitHub repo is being ignored https://github.com/speedruncomorg/api/issues/125
Due to this bug it's impossible to obtain every run from the most popular games the intended way rendering many projects/tools/bots unusable. Trying to work around this bug by, for example, requesting runs per category results in lost runs from deleted categories, slower results, hitting the request limit faster and won't help once categories grow past 10000 runs.
I understand that the API doesn't give ad revenue but it's an important tool for many communities and needs to be kept alive.
@Camcorder this other issue https://github.com/speedruncomorg/api/issues/125 is probably related to the performance tweaks
Currently the API only returns "verify-date" on approved runs and there's no "rejection-date" equivalent for rejected runs. This date is already being tracked since it's visible on the run's page 
Without this date it's impossible to calculate stuff like how many runs a verifier has verified over the last 30 days or the length of the verification queue at any point of the leaderboard's history. Seems like an easy to fix oversight that requires little effort and no breaking changes for the API response schema