Hi, I’m developing a flutter app with firebase + Dgraph as the backend solution.
As a solo developer, so i need to be cost-conscious and want to be prepared if the user base of my app suddenly rises to 1 million users. (dreaming ) (Would be sad if I could not afford to run my service if it would be a hit, due to wrong decisions around my backend)
As my app is structured today, each user will read their node once a day (evenly distributed throughout the day, for example, if I have 100,000 users, it will be 1.16 requests per second around the clock) and the more advanced querys that affect tens of millions of nodes will occur relatively less frequently as they are not controlled by the users but by an external source (And the number of advanced querys does not depend on the number of users but is constant).
Slash GraphQL unfortunately becomes very expensive due to the minimum cost of 1 credit even if I only read one node which is 99% of my requests. I found a post (Slash GraphQL Pricing) that you could pay a fixed price instead (but i find no information on the website about that option) based on CPU/RAM/Storage.
1: But then comes the question of how much it takes to run my querys?
2: What can an instance do? (4GB RAM Alpha / 1GB RAM Zero / 20GB Storage / 40GB Data Transfer - $149/month)
3: “Bonus question” what is the difference between RAM Alpha and RAM Zero?
Option three is to run a local instance of Dgraph but i can not find price information on the website. (Only contact Us) Which makes it difficult to compare alternatives. I could have asked this question directly to Dgraph support but i thought that several other people might be interested in an analysis of cost alternative.
Technically, I’m very happy with Dgraph so far, i have used both Neo4J and TigerGraph earlier but I find Dgraph easier to work with.
Hope someone can come up with some input on how I should think about the costs when / if my app grows.
Based on this, it sounds like you can start with the Standard plan and be well under 100k credits/month. That should as you start and grow your app. As you start to grow, you can look into the higher plans as you find the need.
That said, do you really need to only query for a single node for a user per day? With the log-scale credit system, you can make better use of Slash GraphQL with fewer requests of complex queries per request instead of many requests of simple queries.
Thanks for the quick feedback, No, there will be 100,000 credits a day with 100,000 users, query for a single node “home node” per day. So I will use the “standard” package in one day. Or have I missed something?
The alternative is, as you say, to use for example firebase Cloud Functions, and make only a gigantic querie and let the cloud function handle the logic and update the clients once a day. But it feels like an unnecessarily complex solution.
Thanks for the quick feedback, I’m not very good at speaking English so would rather have a discussion in text format either here or via email
The app is currently in closed beta testing and it will probably take 6+ months before it is ready to be launched (solo project). Sounds good that you are launching a higher plan with 1M credits.
My app is a “subscription service” where all users get an update daily with “optimized” information. My external source enters new information into the graph daily, recalculates the data and updates all users’ “home” node so that users can retrieve their “optimized” personal information through a simple call to its “home” node once a day.
You have no plans to extend the log-scale credit price plan downwards? For example: A query that accesses <= 10 nodes costs 0,25 credit A query that accesses <= 100 nodes costs 0,5 credit
) (Would be sad if I could not afford to run my service if it would be a hit, due to wrong decisions around my backend)