The maker plan says that I can have unlimited personal users who can sign into my app, but the Maker plan also mentions that I can only have 50k rows. How am I going to store the user personal info if I have more than 50k users?
Thank you very much.
I look at it this way:
You are not limited by the number of users, but all plans still have other limits to consider. The fact that there is no enforced limit to the number of users means you have unlimited users. It does not mean you also automatically have unlimited rows, updates, storage, etc. Point being, nothing is going to prevent a billion users from signing in, but your other limits will prevent rows of data from being added once you hit that limit.
You are not required to utilize user profiles, which would in fact allow for truly unlimited users, but that doesn’t seem to be your case as it sounds like each user will have their own user data row.
If you have more than 50k users, a $60 plan may not be the right choice. You would maybe need to contact sales for an enterprise plan or a use different platform. How many total users would you expect?
2 Likes
Hi Jeff
Thanks a lot for your quick and detailed response. I am expecting to have more than 500k users. Each user will need to input his/her unique profile to make certain functions work. My questions are
- Do I have other options to store the large scale user profile data? Such as using a external data base?
- What’s the price for additional rows?
- If I don’t save each user’s profile in the sheet, can I create a guest function so that I can temporarily record user personal information in short term without storing in a row?
Thank you again for your help.
1 Like
You can do this with user-specific columns, for logged in users they save for each user, but for non logged in users they are session-specific and reset when you reload the page.
Honestly, for something of that scale, I’d be in communication with Glide Sales to see if they can provide more of a custom solution with an Enterprise plan. Your project may be out of scope for Glide with the standard plans, but only they can answer that. I don’t think you are going to get anywhere near 500k users to work with the standard plans.
I believe user profiles specifically need to use a glide table data sources. You can use other external data sources or Glide big tables for other things, but they do have certain limitations compared to Glide tables. You could technically store user data in other tables, but you lose the global availability of those values via the user profile. There’s ways around it though.
Well, that’s not easy to answer. There’s no direct upgrade path for additional rows other than switching plans or switching data sources. The available data sources depend on the plan you have. Some limitations for rows are technical limitations while others are plan based limitations. You would definitely be looking at the offerings in the higher up plans, or seeing what Sales can offer.
Yeah technically you could do something with user specific columns. If users don’t sign in, user specific columns would hold values only for the duration of the session. If they do sign in and you unlink your user table from the user profile configuration, you could avoid having a row for each user, and they could store values permanently in user specific columns in other tables. Not sure how that scales for that many users, but I’m not aware of any actual limitations to the number of values that can be stored in user specific columns.
Overall, Glide is more B2B based with apps that have a much smaller user base. The exception is the Maker plan, which is restricted to users with a personal email address. More for business customers or personal projects instead of businesses themselves, but still on a smaller scale than you are looking at.
Contact Sales and see what they have to say.
2 Likes
You can host your user database outside of Glide and fetch user credentials during a custom login process. However, you will lose some of the benefits of Glide’s native user system, which will need to be compensated for with workarounds.
Glide already offers robust authentication out of the box.
Glide’s ethos is to offer a platform that includes quite a few features: authentication, storage, security, design, integrations, scalability, a builder that integrates a backend, a frontend and actions, etc. I think we could avoid circumventing these features and possibly suggesting hacks that would not be in the community’s best interest.
It’s up to the developer to decide how to scale the project — there are many ways to approach it. I’m not sure what you mean by “community best interest.”
He mentioned having over 50,000 users, which could cost him quite a lot of money. He might consider other options or even abandon Glide altogether. Would that really be in the community’s best interest?
1 Like
Either Glide can safely accommodate 50k users with its native features, or it cannot. The idea to “fetch user credentials during a custom login process” that would not use Glide’s native authentication and would probably not be safe. This would not be in Austin’s interest.
As Jeff suggested, Austin can contact Glide’s sales team directly.
You can safely fetch data, and you can also encrypt it. As I mentioned, there are many ways to handle this, depending on the requirements, budget, and skill level. As you noted, the easiest — but likely most expensive — option is to contact Glide’s sales team directly.