"Database bandwidth" Discrepancy
Hi, I'm seeing a big discrepancy between the "database bandwidth" value displayed in:
1. The top table on the usage page (500.6 MB)
2. The aggregate "database bandwidth" of all my functions (8.47 MB)
Both values are showing the usage only for today 18th Nov. I'm struggling to debug what led to the sharp increase in database bandwidth read, since the high database bandwidth is not showing up on the "per function breakdown" section. Could I get some help to understand this discrepancy?
In case that helps, today I started implementing the aggregate component, and I find it suspicious that I see the function calls for aggregate queries but the database bandwidth incurred does not show up
4 Replies
Hey there, I can confirm there seems to be an issue where the function breakdown is not showing all of the data, undercounting some usage. The usage you see in the summary (First screenshot) is correct.
We're working on a fix for that, but in the meantime, it looks like a large chunk of your usage came from clearing a table in the dashboard. At the moment, clearing a table via the dashboard will encounter db bandwidth for the size of the table. Alternatively, you can delete the to not incur usage
We identified and fixed the issue with function breakdowns, you should now see the numbers in the breakdown add up to the numbers in the summary
Thanks for helping us find this bug, and I've also noted that we should improve the "Clear table" functionality so it uses less bandwidth. I added a temporary exception for your team -- your projects will keep running if they go over the limits this month
You said we are charged for deleting data from a table in the dashboard and proposed an alternative but you didn't actually say what that was. Would be good to know how to not incur bandwidth usage when I'm mass deleting :).
Ah sorry, typo in that message. There’s also a “delete table” button which should delete your table more efficiently. You can then recreate the table, but it will only work if you first remove the table from your schema.
This is understandably also not ideal, and we should expose a better option
Thank you!