Hello all,
I have a dummy question about pricing. If on the maker plan we can have “unlimited” (up to 1 M users) how can the system work if you only have 50k row allowed by app which count user table??? Or did i get something wrong here?
It’s not a dumb question
You are still restricted to users numbers by the maximum rows for your plan.
This is related
3 Likes
Thanks @Rosewebstudio indeed it’s related and while I will not go on an accusation path, I can only support the argument. Why give an info that you can have upto 1m User when it’s not even technically possible. I thought it would be for having multiple apps but no the limit is per apps which is even great. It’s quite disappointing when you think about a project, you build it, and at the end because an improper “marketing” info you need to rethink everything. I was planning to move my mvp anyway when it was the right time on another platform, now I have to think about this way sooner than I thought. Glide is a great product but this misleading info isn’t right. Would be glad to have a Glide team member to clarify.
1 Like
I don’t think I’ve ever seen a documented claim of 1m users, unless it was maybe old documentation… Unlimited simply means that Glide does not impose a forced limit on the number of users that can sign into your app, unlike it does with other plans. In other words, you will never see a warning indicating that you have hit a user cap with the Maker plan. However, that does not discount the other limits that are imposed under the plan. Update, Row, and Storage limits still very much apply.
Should you be able to store unlimited terabytes of data if you only have a few rows or only have a few users? Should you be allowed to run unlimited server side workflows using server processing resources if you only have a few rows or users? Point being is that one limit does not dictate another. They should be treated as separate independent limits regardless if one indirectly affects another.
You could technically have more users than there are stars in the universe and glide should never present a warning that you have hit a user limit, but that doesn’t greenlight you you use the entire worlds worth of database storage and processing power just because it said unlimited users. That’s why there are other types of limits that apply.
If you choose not to utilize user profiles, then sure you can technically have unlimited users, so long as you don’t exceed any other row, update, or storage limits. Otherwise, if you utilize user profiles and a user takes a up a row, then that is still space in the database being used to store that information.
Just to reiterate, unlimited users means “not limited”, or “no limits imposed” to the number of users. Meaning Glide won’t stop you from trying to have as many users as you want. It does not mean that other limits no longer apply.
3 Likes
Thanks for your reply @Jeff_Hager. I get your point, but the message is a bit misleading, won’t you agree?
Number of users ( and I mean by the definition it is given, see screenshot) whether or not you have user table is the same you will always be limited by the number of rows. This is a marketing messaging strategy that can work up to some point but has it’s limits. If the limitation is the number of glide table row ok, no problem but make it clear that there is maybe another solution required to have your unlimited users. Business plan are a bit more precise.
Glide is really a great solution but I am really disapointed by this issue, mainly for my project, or maybe i did get something wrong.
Limitations are normal but should be clearly stated. I did see the issue early, maths didn’t matched 
but hopped.
I’ve managed product go to market strategy and my worst enemy for me for my clients was marketing so I know what i am talking about
I am in a very early stage but business planning require visibility and there i just lost it.
1 Like
I can understand where it would be confusing. It’s never been confusing to me personally, but I’ve been very active here for several years, so I’m familiar with the nuances. I think Glide just puts in an arbitrarily large number like 1 million so the programming does not prematurely trigger a warning and stop allowing users to sign in. The code just needs a number and they could just have easily picked 25k, 500k, 1 billion, or 10 quadrillion. I think the intention was to have a user limit that would never be realistically reached with the Maker plan when paired with all of the other limits.
I agree it could be better documented that “unlimited” is an arbitrary number, but people would still complain if they said 25k users or less (which then doesn’t allow much or any room for anything more than just the user rows in the entire app database). Plus they still need to account for the rare instances where someone may not utilize a user table which theoretically could then allow a million users, albeit with very little data entry from those users, even though Glide may have some important ‘questions’ at that point since there is still internal user data being stored that you don’t see in your set of tables. I think the whole purpose of the Maker plan was for apps that are forward facing customer portals that supplement internal apps on a business plan, or something used by a smaller non-profit, educational group, or for small private projects (thus the term ‘Maker’). The plan was added to fill in a gap left by the other plans that had stricter user limits, while only allowing personal user types only.
Fact of the matter is that Glide apps have never really been intended to serve a mass number of users per app, and for the cost of the plans, I would agree with that knowing what costs are typically associated with much larger operations. Their focus has always been on internal business apps, which in turn would typically mean a smaller user base per app.
To service a mass number of users, data, and subsequent processing would take much more capital to cover the costs of server storage and processing time. Where I work, we used to host our own servers on our own hardware at multiple locations up until a couple of years ago when we migrated everything to the cloud. Whether it’s our hardware or someone else’s, it still costs us hundreds of thousands of dollars to maintain the hardware and the IT staff to develop the software and to keep all of it running. I wouldn’t say our user base is huge as far as those that actually sign into our system, but we do service several customers across the country, and our database storage is well into the thousands of tables, billions of rows, and terabytes of storage when everything is all added together. We don’t use Glide where I work, but I just wanted to give an idea of what requirements and costs are like when you start to scale up to something much larger. The unfortunate truth is that it’s not cheap.
I guess I like to think realistically when it comes to things like this. Some think Glide is expensive for what it offers while others think Glide is extremely cheap. It’s all perspective and depends on the use case and cost vs benefit. While I’m not totally on board with the pricing and limitations since I only deal with small personal projects and a couple apps with no more than 2 to 5 users, I still think what Glide offers is respectable for the price. There are definitely still some gaps in the plans and Glide apps don’t cover all use cases, but it’s still cheaper than the alternatives in many cases.
At the end of the day, I think the most important takeaway is that it needs to be stressed is that each Glide user needs to take the time to study each plan at the very beginning, understand the limitations of each plan, and evaluate if their needs fit within each of those plan offerings. This is something that cannot be ignored until later. If the primary plans do not fit the use case, then it may be worth contacting Glide Sales to see if they can offer a custom Enterprise plan. If none of the plan offerings and their limits fit within the requirements, then Glide may not be the best option.
5 Likes
Very Well said @Jeff_Hager. My two cents here is that I understand that cost and limits being independent of each other is fine but then the gap between row limits and the allowed no. of users on the maker plan for instance is a tad bit too much and can be narrowed down by just increasing the row limit (maybe it can be 100K rows on the maker plan) and they could possibly charge for it like they do for unlimited updates. Just having the option of being able to get access to more rows based on cost(like WU in bubble) would make glide a much more attractive option for free lancers who want to build scalable products.
1 Like
This is a really important clarification - thank you @HouseSnap for raising this and @Jeff_Hager for the detailed explanation. I’m building an app that requires user profiles for core functionality (matching, stored preferences, personalized features). now that I know the ceiling is ~25k users rather than “up to 1M”- I’m very concerned about architecture planning. I appreciate the technical accuracy that unlimited = no enforced user cap, but for apps where every user must have a profile, the 25k limit seems imperative.
before I start planning platform migration, do you know if there any options within Glide that could work around the 25k user profile limit? or is migration inevitable for any user-profile-dependent app targeting six-figure user bases?
I love what I’ve built on Glide for MVP stage, so I’m hoping there’s a path forward I’m missing…
2 Likes
Is the 25k user profile limit per app or per project?
User limits are enforced at the Team level. In fact most limits are at the Team level. The only limit at an app level is Row count.
1 Like
it’s per apps. Use eventually Big Tables if possible it will extend your limit for your MVP.
Thank you @Jeff_Hager and @HouseSnap
I see Glide is great for MVP, but seems like it has a hard tech ceiling that can’t be overcome for our use case.
1 Like
You’re mostly on the right track. On the Maker plan:
-
You can publish 3 apps, each with 25K rows (GT not GBT), so yes, that’s 75K rows total for user data.
-
The “up to 1M users” limit refers to active users over time, not simultaneous rows stored. In practice, you can delete or archive old user rows to make room for new ones, which is why the system can support far more than 75K individual logins over time.
So your understanding is correct: the hard row limit per app restricts how many users’ data you can store at the same time, but the 1M users metric counts all users who log in over time in a single account, not a single app, even if their rows aren’t kept permanently.
Am I wrong? @Robert_Petitto @Rosewebstudio