Parse Pricing: Now Cheaper and Simpler(blog.parse.com)
blog.parse.com
Parse Pricing: Now Cheaper and Simpler
http://blog.parse.com/2014/04/30/parse-pricing-now-cheaper-and-simpler
3 comments
I'm doing about 15m/mo and my peak req/sec so far is 24 which looks out of the normal cycle by about 2.5 req/sec. We can double our limit for a lot less than what we're paying monthly now so this is a welcome change for us. I would think retrying 155 responses would work ok for us while refactoring to reduce calls. I think the new offline data store ability will help with reducing requests.
I've been using Parse for a few years now and have always been happy with them. Their service offerings have been growing right along with my needs so it's been great. I'm happily welcoming this announcement.
I've been using Parse for a few years now and have always been happy with them. Their service offerings have been growing right along with my needs so it's been great. I'm happily welcoming this announcement.
Thanks janj! What type of app do you use? Is it gaming-heavy, text-heavy, etc?
It's a social app for people who vacation on cruises. You can create a profile, store cruises you've been on or are going on in the future, communicate with fellow cruisers, submit pics, reviews, etc. All of it is done through Parse. We also utilize Parse's Cloud Code to send data to the parent company's web site. I'm sure we're not using Parse to its full potential but we're a small group right now.
That's good to know, appreciate the insight!
I feel the new price structure is a welcome change. Regarding the req/s limit I also at first felt I would be able to hit it easily, but the more I've calculated it I can see I will be nowhere near that limit.
I've made an native iOS app to use the Data Browser from the phone. It's something I think a lot of Parse users can benefit from using, I wish they'd informed about it in their presentation!
I've made an native iOS app to use the Data Browser from the phone. It's something I think a lot of Parse users can benefit from using, I wish they'd informed about it in their presentation!
This makes a "fan-out" model for any feed-type app pretty difficult. For example in an app with friends or followers, when a user posts something the app would perform inserts to add the post into the followers/friends feed tables. It's very bursty, and would be very expensive with this new pricing scheme.
Yes, but this assumes that all users are online with the app active at the same time and that the app is requesting the new info at the same time, right? How likely is that, really?
This actually has nothing to do with who is online or if the app is currently requesting info. An example:
You have a posts db table (or collection in the case of Parse, since they're using MongoDB) and a user_posts table. The user_posts table contains references to the posts to show in each user's personalized feed (fan out model). When a post is created, the app needs to perform x inserts into user_posts, where x is the number of users who's feed will include this post. EACH insert counts as a request in Parse, so if a user with 100 followers posts something that needs to be distributed to the 100 follower feeds, that'll require 100 requests/second.
You have a posts db table (or collection in the case of Parse, since they're using MongoDB) and a user_posts table. The user_posts table contains references to the posts to show in each user's personalized feed (fan out model). When a post is created, the app needs to perform x inserts into user_posts, where x is the number of users who's feed will include this post. EACH insert counts as a request in Parse, so if a user with 100 followers posts something that needs to be distributed to the 100 follower feeds, that'll require 100 requests/second.
It seems to me that a smaller app would be more likely to occasionally burst over 30 req/s than go over 1m req/mo. Is it as simple as retrying requests that return error code 155 (per the FAQ)?
https://parse.com/plans/faq/