

Parse Pricing: Now Cheaper and Simpler - janj
http://blog.parse.com/2014/04/30/parse-pricing-now-cheaper-and-simpler

======
owensbla
I was initially happy about this, but the more I think about it the more I'm
on the fence. I'm just starting to get in to using Parse this week, so can
someone with a little more experience give some thoughts?

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/](https://parse.com/plans/faq/)

~~~
janj
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.

~~~
whatthewhaa
Thanks janj! What type of app do you use? Is it gaming-heavy, text-heavy, etc?

~~~
janj
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.

------
carlfranzon
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!

------
marbemac
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.

~~~
carlfranzon
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?

~~~
marbemac
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.

