kden
非常同意，这样leancloud根本不能吸引小众app开发者了，可是所有的大众app曾经都是小众app。直接忽略了小众app 开发者的需求，我觉得这不太适当吧。我的产品快要上线了，现在非常纠结。一个根本未被证实的app保底就要900一个月，很有压力啊。国外的Firebase反而要厚道许多，可选择固定价格的plan，也可以选择弹性价格的plan。唉，心碎了。 曾经Leancloud最大的优势之一就是弹性收费，现在这没了，我猜很多人（尤其是未接触此平台的人）会跑去bmob之类的吧。 就算没有弹性收费，也可以加一个0~900之间的选择么
实话实说，我的产品快要上线了，加上我只有3人的公司。当初我是衡量了很久，觉得Leancloud各方面综合最好所以才选用的。中间学习其SDK踩了不少坑（还是不错的，文档问题吧？），然后现在才突然来个新年快乐，月费900啊。。我还说服了我的伙伴说用Leancloud是因为性价比高，可提升开发速度，适合初创，现在简直是懵了。。 可以新增一个0~900之间的选择么，唉。 900包括了很多不是所有用户都适用的东西，例如工单系统，无限API次数等。通常成熟的企业已经有自己的前后端工程师，选用Leancloud的意向就不会这么大了吧，毕竟学习这SDK也要冒着踩坑的风险。 反而初创因为人员少，技术框架什么的调…
唉，希望能有转机吧，不然不知道要怎办了。 这是要把所有小众app赶出平台的节奏吧 我觉得最低100~200已经可以赶走大部分没打算付钱的用户了，真的不用一下子900吧，太过了。
噢噢。。被你们的邮件搞得混乱了，现在应该不少人（包括我和楼主）都以为开发版没有原来的按需付费，超过了限额就要被逼上商业版吧。。吓死人了 哈哈 还有就是结构化存储可以按需要求超过 3 个工作线程么，3和30之间有很大的差别呀~ 一些应用可能需要用到10，一些可能20。
3~30之间有很大的灰色需求地带呀，有一些可能要用到8，一些可能用到15，一些可能用到20多，可以发邮件去要求调升这线程数么，不然还是有逼人上900的感觉。。
是的江总，价格页面和邮件都很容易令人误解呀，致命的误解 这里只说明了免费额度，却没有说超出了该怎么计算，然后下面就直接是900的商业版了，让人以为 只要超出了免费额度，就一定要上900的商业版 粘贴的图像 1635x594 130 KB 建议可以参考下firebase 的pricing页面，觉得还不错 粘贴的图像 1865x1729 297 KB
感谢江总的回复，比blog文章和官网要清晰不少。 我明白一般后端都会有固定初始成本，不过当初Leancloud的卖点之一就是收费弹性，不过免费额度不用钱，过了也是按需收费。当初我就是被此吸引的，不然也会自己搭伺服器。我个人认为这也会是潮流之一，例如Firebase等，也是Serverless及弹性收费。 不是付不起900，而是在想0到900之间就没有第三选项了么，难道一个月30天，有那么几天超过30000的API要求就要用到商业版么。 除了把你们的固定初始成本一开始就转介到用户身上，就真的没一个供初创/个人的中间选择么，因为企业也是分大小和不同性质的，例如我在另外一个帖子所说的： 若然只想赶走…
请问腾讯TAB会有类似的价格变动么？如果不会有，而新的价格方案维持这样，可能我就会迁移了
騰訊TAB也是希望之一。。。
也是的。。唉 果然PAAS长远靠不住啊，Parse说倒就倒，Leancloud说900就900，小额用户无所适从啊 看下图TAB优势 红圈的那栏，这本来就是Leancloud相对于传统移动开发的优势，可是现在他们决定最小化这优势了 哈哈 希望能有转机吧。。。
希望LeanCloud 可以理解一下我们这些小额用户吧。。我相信他们是想履行80/20定律，就是把80%的资源集中在20%的高端用户，因为这20%的高端用户可给予他们80%的收入。可是我想说的是，小额用户虽然为Leancloud带来的收入不多，可是为社会各行各业带来的效益加起来肯定不会小的呀，就像是你给学校开发的应用。我宁愿取消所有的免费的限额，也不想见到如今不是免费就是900的局面。。毕竟很少人用Leancloud不会用储存API吧。。
看来也只好这样了，毕竟我们这些小额用户只是他们盈利的冰山一角，太多的小额/免费用户反而对他们的技术支持造成负担。恐怕就凭我们这微小的力量在社区吐槽，是无法改变什么的。毕竟商业公司就是以股东利益最大化为最大目标，只好认命了。。希望此举能令Leancloud 不走Parse的老路就是了
嗯，我本来也觉得原来的免费限额太慷慨了，担心会不会影响付费用户的服务质量。。只是没想到收费改动来得如此突然无预警，幅度如此之大，完全是推翻了当初选择Leancloud而非AWS/Azure之类的一大理由（高度弹性收费），造成极大的心理落差，难以平静去面对。。尤其是投入了大量时间在学习SDK和克服各种坑的过程之后。这就像是跟一个女人结婚了才发现她以前是男人。
嗯。。对了，其实改变不了日限30000，为什么就不能直接月限30000*30=900000呢？大部份同类产品例如bmob也是类似，我觉得这直接就解决了我目前在此看到的最大吐槽之一，就是平时没啥流量的小应用，一到某某时候如果超过了30000就肯定要上900月费才能稳妥了。月限也解决了需要各种复杂技术去降低API存取数的必要性。。。（这不是与Leancloud简化后端代码的宗旨背道而驰么。。当然，90万不够我们还是会付费买雲引擎、缓存等服务的，甚至也会上900的计划） 月限90万，我觉得这是比日限3万更好的方案吧~ 就正如为什么大部份3g流量计划都是月算的，因为每天的用量需求是浮动的，日限的话会对…
感谢张总在这为民解忧~ 嗯。。我同意直接月限的安全隐患，还有就是确实不小心就可以耗掉整个月的流量了。同时，虽然做客户端的开发者一开始不太熟悉后端的逻辑，容易犯错。可因为犯错成本高，他们也会逼使自己成长的。除此之外，他们也会想方设法使应用稳定，及让流量也跟着成长的（除非他们不想赚钱）。这成长中的流量需求就包括了浮动的流量需求（例如周末vs平日） 这次改动这么多人在吐槽的原因，我在上面提过的一点就是：新的日限30000满足不了他们的浮动需求。也就是说，也许他们一个月是达不到90万的，可仅仅因为日限30000，导致浮动需求大的小应用直接不能用了。 那么可以在默认日限30000的基础上，在后台新增一个…
嗯，明白了 江总。一分钱一分货，便宜、可靠和省人力只能选两样吧。现在Leancloud走的是可靠和省人力路线吧，也希望Leancloud可以从此更可靠，SDK质量更好。