Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • smercer 39 posts 67 karma points
    Mar 21, 2011 @ 21:24
    smercer
    0

    How many members can umbraco handle?

    I am porting a site to umbraco that has well over 600,000 members and I am debating whether or not to keep this member data in custom tables or to migrate into umbracos member system. I could see this being close to 1M members in the next few years. Is the Umbraco member admin UI built to scale this much (assuming there is enough database horsepower to back it up)?

  • Shannon Deminick 1508 posts 5163 karma points hq
    Mar 22, 2011 @ 02:03
    Shannon Deminick
    0

    I would keep it in your custom tables. This means less work for you, and you already know your custom tables support this much data. Umbraco supports any Membership provider, not just the built in Membership provider so if you are using the SqlMembershipProvider, Umbraco will recognize that. If you don't have a membership provider linked to your existing members then it's pretty easy to create one and plug it in.

  • Shannon Deminick 1508 posts 5163 karma points hq
    Mar 22, 2011 @ 02:04
    Shannon Deminick
    0

    Umbraco splits data across many tables and isn't really optimized for reading performance which is why there is alot of data caching in Umbraco. having that amount of members and if you are querying member data quite a bit could slow your SQL db down a bit (it will be making quite a lot of queries). So yeah, I'd stick to your custom tables.

  • smercer 39 posts 67 karma points
    Mar 22, 2011 @ 03:23
    smercer
    1

    Thanks for the replies, guys.

    On front end, we plan to memcache member data on login, so unless the member edits their profile we shouldn't have too many reads going on. It's the admin that I am potentially concerned about. My main reason for wanting to go with the umbraco solution is that it would save us from having to build an admin console (currently we don't really ahve an effective one) - but I don't want to waste my time if the member admin doesn't scale well.

  • Shannon Deminick 1508 posts 5163 karma points hq
    Mar 22, 2011 @ 05:23
    Shannon Deminick
    0

    Yeah, I would stay on the safe side with your custom table especially if you ever wanted to run reports against your member data or export it, that would consume a huge amount of SQL using the Umbraco data store in comparison to a single query.

  • Chris Ashton 51 posts 81 karma points
    Aug 15, 2018 @ 23:03
    Chris Ashton
    0

    Hi Shannon,

    I'm wondering if for 'large' membership numbers you'd still recommend using custom tables?

    I have a site that could conceivably have ~50,000 members – is there a ball park threshold you would recommend using custom tables?

    Many thanks,

    Chris

  • Shannon Deminick 1508 posts 5163 karma points hq
    Aug 16, 2018 @ 03:44
    Shannon Deminick
    2

    Wow that's a blast from the past!

    Umbraco's membership can handle tons of data these days, just make sure you are running on latest version.

    you'll have no issues with 50k members

  • Chris Ashton 51 posts 81 karma points
    Aug 16, 2018 @ 11:31
    Chris Ashton
    0

    Perfect, the answer I was hoping for! Thanks Shannon :-)

  • Stephanie Yost 1 post 71 karma points
    Aug 17, 2020 @ 20:40
    Stephanie Yost
    0

    Checking in here for 2020, any concerns with 1M+ account holders scalable to 3-5M?

  • Tim Geyssens 6562 posts 15373 karma points MVP 2x c-trib
    Aug 17, 2020 @ 22:45
    Tim Geyssens
    0

    well not sure if the umbraco implementation of members would be able to do that... since the whole data structure (since you can add custom properties and all) might be difficult to efficiently query... (a core member like shannon might be able to provide more data).

    However under the hook it's just standard .net membership stuff... so you could swap it out for something that can handle it

Please Sign in or register to post replies

Write your reply to:

Draft