Each Realtime Database instance is essentially running as a single-threaded process on our servers. The load that you see in the usage chart is an indication of how busy that thead is. This means that if you hit 100% sustained load, there's not much more you can do than reduce the amount of work you make the database do.
To scale the Realtime Database beyond that, you have to shard your data over multiple instances. This is one of the big differences between Realtime Database and Firestore: the latter handles scalability automatically for you, while with Realtime Database you'll have to think of it more yourself.
Coming up with a sharding strategy is something best done early in your data modeling phase, typically around the same time when you start thinking about how to secure access to the data. If you have a specific use-case and are wondering how to shard it, I'd always recommend posting to our firebase-talk mailing list as our team loves to think along with those.