I’m seeing tons of conversations about moving. It’s scary.
@emmanuel consider a complete roll back of this announcement and a try again soon, if you’re up for it!
I’m seeing tons of conversations about moving. It’s scary.
@emmanuel consider a complete roll back of this announcement and a try again soon, if you’re up for it!
I’m wondering what features you’re thinking of at each level.
Also, I’m thinking the number of users at the first two tiers may be overly generous, but I have no vision for what kinds of apps might be deployed at these levels.
Thanks @emmanuel for the transparency here and listening to all of the feedback!
Regarding charging by database usage, I think it’s just a matter of just changing the metrics to gigabytes of database storage used. Obviously we already have the file manager capacity which is directly tracked in the logs, but if you look at google firebase they seem to track by the amount of storage you use rather than the number of objects:
So this really opens up a key question and I think is the core of the issue here…are we going to be paying for individual database line items that are text only and literally individual kilobytes of space or none at all, and should those database objects all carry the same uniform pricing whether they have only text, only media, or a mixture of both? It seems weird to me that a database thing that has 40 columns, with 10 of them holding media files and other files, and sometimes lists of them in an individual field, should be weighed equally against simply text objects that take up no space.
I know you guys said tracking the database size is technically challenging, but I would say that there needs to be some type of weighting algorithm developed that assigns a weight to individual database objects so that they can be priced accordingly. I don’t think there would any issue from users paying more for very media and file heavy database objects that stress the systems, while leaving people who just have 100,000 text based database items as is. At the end of the day, what puts more stress on the database/systems, 10 people each with 100 database line items that have 40 pictures in each of them, or 100000 people with 10000 text only database entries?
Thanks for the consideration as always.
Spot on. This isn’t about complaining about higher prices. This is an existential crisis. Decisive, swift action is absolutely critical.
Yeah, I know, but that’s something they should struggle with and see how to make money without killing all the apps hosted in bubble.
Just an example: I run a couple of servers on DigitalOcean running very complex solutions hosted there, I have GB limits, CPU limits, and data transfer limits, and I’m more than happy to select the option that runs for me. They have like 100 possibilities for all the targets, from $5/month to $2500 or custom pricing for higher needs.
But forcing everyone to move to the highest tier plan because of row limits or entry limits/month it’s a terrible idea.
I work in a bubble app with 1,200,000 records in the database and can’t delete them as it hosts logs and customer data. The app it’s paying now $520 production + 4 boost + 5 storage boosts. If they decide to go with this pricing, the app would pass from paying around $700/month to $4000
Workflows run makes even less sense than capacity. Not all workflows or actions require the same level of processing power. Capacity is a much better metric, it just needs to be broken down better for a Bubble user to be able to digest.
No pricing system will be perfect. I prefer the current setup (charge based on processing capacity). The beauty of that system is that as an app’s usage grows, so does its ability to monetize, and so does its ability to justify higher costs.
Plus, and importantly, that’s the approach you sold to your users when they signed up. If you switch the approach, you damage user trust and cause your users to think Bubble lacks integrity in its business dealings.
If you feel like the unlimited database rows feature is being taken advantage of, then you can set up some really high limits that solves the issue with those edge cases without impacting the majority of your user base.
I don’t think that would stop the exodus… We don’t want to delay moves that affect our business and hope for a better result. I am hoping for a new, ‘permanent-ish’ change to the pricing that is more reasonable. I can’t afford to wait and hope, trust is really hurt here.
I don’t mind having limits but limiting records is the worst way to do it. For context, a 500 MB storage space is enough to store 890k tweets (280 words each) thats more than enough storage for any amount of startup or MVPs.
I can’t even imagine a limit of 5000, thats truly bad for someone who has been building on bubble for the past 2 years and our career depends on it.
A thing with 2 fields and 100k rows is very different than a thing with 100 columns and 20 rows.
CPU capacity + total database GB used
I understand dB storage may be hard to calculate on your end. Perhaps that is a technical challenge that can be overcome by some software engineering effort.
But from the community perspective, that would keep it simple.
Thanks
ZubairLK
Database storage was my first thought at how to do this. Two different database records could be very different sizes (a blog post vs a user-created category for example), so I don’t think it makes a lot of sense to index off of those.
exactly, worse than a price change is a conceptual and structural change, which compromises our apps in everything.
Impossible to scale and make any business viable. With the feeling of fear and ending up with everything I built with the bubble is great.
More basic plans don’t have much room for the business to start spinning and the bigger plans undermine better established businesses. They change so much the model that generates distrust, that from one moment to the next we can have the whole business unfeasible, as in the beginning and in more advanced platforms, evaluate other platforms.
If they want to stop selling Databases in the plans they could offer their own plugin and well modeled with AWS for example or start charging for usage based on the negotiation they already have with maazon. In the same way that today the integration with google maps is native, they could earn more and make the business viable.
What would the price per entry need to be to hit that same $700/month?
Seems to me that bubble needs more money from the bottom not the top.
Do you know how many records you create a month?
I don’t think too many people are against the change in general, its just the type of change and the low limit of items. If you were to increase the limit, you would be fine, just need to find that limit. Regardless, with a limit on Items, I feel developer’s are going to skimp on good database design to save on the cost of limiting items. Pricing might be correct, but bubble will have poorly designed apps due to this limit.
Limiting GB size might be hard for you guys to display to us, but if you can find a way to do it, I think it would make the most sense. This still allows us to create apps that are designed well and don’t have to worry bout the amount of items. You can still charge us overage fees if we go over our GB size so apps don’t get limited. And it keeps us developers in check to make sure we have clean databases if we don’t want to pay the overage fees.
This being said, the database GB pricing model still needs to be reasonable. Can’t be paying $300+ for a production plan and only get 5gb of database storage.
Already gave my 2 cents at my previous post:
Now, the good news is that there’s still time to turn this price change into something positive:
Increase monthly unique daily visitors 2x and database things 20x.
It would be something like this:
- Personal: 20.000 unique monthly daily visitors (666 daily unique users) and 100.000 database things.
- Professional: 100.000 unique monthly daily visitors (3.333 daily unique users) and 500.000 database things.
- Production: 200.000 unique monthly daily visitors (6.666 daily unique users) and 10.000.000 database things.
And make it clear as how much will exceeding users and database things will cost.
Then, I believe your goal would be achieved: Bubble would have a simple and clear pricing plan with objective metrics, allowing Bubble-built apps to scale.
However, here’s a suggestion: if in doubt, don’t touch it.
Is Bubble pricing per capacity ideal? No.
But is it a problem that needs adressing? Also no.
Again, speaking not only as myself, but as a spokesperson for 25% of Bubble users: we do not have a problem with Bubble’s pricing model.
My advanced students know exactly how to read their Logs and optimize their Bubble apps in order to always achieve the best possible capacity. And when they need to upgrade, they just do, it’s fine.
What we really would like for Bubble to improve is Repeating Group performance, the API Connector, the Rich Text editor… There’s a lot of things that need improving in Bubble - pricing is not one of them.
Hi @emmanuel first of all, thanks for listening.
If the end purpose of this change is to force people to make more efficient apps, hence make bubble more efficient, then you should’ve started with coaching developers on this, making a couple of high quality videos and bootcamps. Most of us come from a non-technical background and Bubble is our first approach to this fascinating world.
Regarding pricing ideas, what I’ve learnt from AWS is that they charge for read/writes or API calls, this is definitely a better indicator of the real processing requirements an app has than it’s sole database number of elements. Storing tons of historical data that is rarely consumed, shouldn’t be punished when the whole purpose of building something in bubble is scaling FAST.
I know shifting to a read/write pricing structure can be unpopular but in the end it’s understandable. We all want bubble to succeed and be our go-to platform so I’m sure users like me will be totally ok with this as long as pricing and limits are set in a logical manner.
all the best!
Depends on the month, some months 60k others 150k
I thought the same thing, planning with amazon could solve this for the bubble and for us at once. Or even with Waasabi that already has a bubble plugin, if @emmanuel thinks more calmly he can solve this.
I know your work, and you’re one of the people I’ve been waiting to speak up, because you’re one of the most positive (at the same time realistic) people with Bubble matters.
The other person I was waiting to speak up also said something here, and he was no different, he was worried about Team Bubble’s decision.
My main app would be released next Friday, straight to production version (already alpha, beta and I’m on the gold version), 10 months of hard work, and lo and behold, I’m canceling the release until I ingest the situation.
The first thought is to get out of the Bubble, I know that there are alternative options, but now I feel insecure, I have lost confidence, I don’t think it’s reliable to build in Bubble something that I need to dedicate so much time to, because I’m watching decisions that make us think that Bubble is in your last breaths.
All this will become a great life learning experience!