After looking at the differences between Firebase and Parse, it seems Parse offers a better package at the free level.
While Parse offers 30 calls per second, Firebase offers 50 simultaneous connections, both at the free level. Assuming they scale comparatively in their paid tiers, I believe Parse is best suited for making apps intended for "the masses," so long as the purpose of the app is not to synchronize every user at all times.
The benefit of Firebase, based on my impression so far, is to keep a small group of active users synchronized in real time. Scaling an app on this model to thousands of users or more would be expensive. While Firebase has the advantage of more 3rd party sign up options, the strength of Parse is the high bandwidth even at the free level, a big help for new apps and app developers.
However, In trying to take advantage of both worlds, how about using Parse as the cloud database (a $9 C2 plugin), and using C2's multiplayer plugin as a substitute for Firebase?
C2's multiplayer plugin has the advantage of allowing you to create "rooms" of users. If you're creating a chat app, for example, the size of the room could go up to as high as fifty. Once a size of 50 is reached, new users would be ushered into a new room, with a new host. The scalability of this approach has no real limit except for how fast C2's server can assign new rooms, and each additional room of 50 users is analogous to a new Firebase account. Since C2's MP plugin creates a direct connection between devices, there is no limit to the number of 50-user rooms C2's multiplayer server or the app can create.
This adds a little extra work upfront for a C2 app developer, but does not inherently risk their app from being overburdened with too many simultaneous users.
Subsequently, any data that is synced with Parse is contained to the app using it, but not limited to the room of 50 users that created the data. In this way, the database is not divided into different "accounts", as would be the case with multiple free Firebase accounts versus one very expensive account.
Simultaneously, Parse resources do not have to be pushed to the limits either. The designated host of the app using the multiplayer plugin can be set to be the only one syncing data with Parse, and sync as sparingly as is practical for the app. That way, more data can be sent per sync less frequently. Syncing non-host users with Parse while they are in the room may not be necessary, because they can sync with Parse at any other time, and their data will be waiting for them.
As a bonus to the app's developer (us), we will have gained not one but two extremely valuable skills: cloud storage (user to cloud data transfer); and multiplayer (user to user). The second skill alone will be a significant "player" in data security, because it will allow customers using our apps to connect directly with their peers if they are less trusting of "cloud" data management. The multiplayer plugin transfers data user-to-user directly. Having sensitive data not even pass through your app's "data server" (which the multiplayer plugin doesn't need), nor through Parse, would be a powerful selling feature of such an app. And what does this feature cost you to implement, scale AND maintain?
Almost nothing.