3 ms·

I'm not the GP. Unrelated to DBs, I've been thinking about trying to roll my own system for magic links recently. Even though Supabase has some of the lowest

by ryan29 3y ago

I'm not the GP. Unrelated to DBs, I've been thinking about trying to roll my own system for magic links recently. Even though Supabase has some of the lowest costs for MAUs, they're still too high if you're only using magic links, especially considering the related email rate limits [1]. I don't even know if I'm reading that right. Is it 4 auth related emails per hour by default? I can run a Cloudflare Worker for $0.0000005 vs $.00325 for a Supabase MAU. Assuming it would normally take 2 Worker runs to generate and auth a magic link, a user that signs up and never comes back would cost me 3250x more if I use Supabase. Not all users are equal and, for low value users that probably never convert to paid users, I don't need to give them a full blown user account with MFA, etc.. Magic link based auth is adequate for what I need and I don't want to pay between 300,000% (for Supabase) and 15,000,000% (for Auth0) markup above the raw compute costs for someone that signs up and never comes back. For a user that converts to a paying customer, I don't really care about the cost as long as I don't have to eat it for every free user I have. I know there are other costs, and that the requirements for magic links are more complicated than at first glance, but those costs are relatively fixed in the context of magic links, right? If the only major ongoing cost is for email, where I'm basically expected to bring my own provider, the MAU cost for a user that only uses magic links feels like a bad deal. This isn't just a Supabase issue either. The entire auth industry is similar. I need the simplest part of the existing solution, but I'm forced to pay, in both cost and complexity, for the complicated, expensive part of the solution that I don't need or want to use. Does that make sense? 1. https://supabase.com/docs/guides/platform/going-into-prod#auth-rate-limits https://supabase.com/docs/guides/platform/going-into-prod#au...

kiwicopple 3y ago
> Is it 4 auth related emails per hour by default? It's unlimited emails per hour, as long as you BYO SMTP provider. The default email service is only for testing, and not recommended for production. I usually recommen AWS SES or Resend[0] for unlimited emails > This isn't just a Supabase issue either. The entire auth industry is similar. Agreed - the industry prices on MAU, which isn't a great heuristic. for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high. For Supabase, we simply try to be fair and transparent (and we're an order of magnitude cheaper than other Auth providers). There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc. [0] https://resend.com/docs/send-with-supabase-smtp https://resend.com/docs/send-with-supabase-smtp
- ryan29 3y ago
  > There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc. Yeah. I was hesitant to toss examples of actual costs in there because I knew it wasn't really a fair comparison, but I wanted to try to make my point even though I don't have the ability to calculate the real costs. If I had to sum it up in a way that translates into a good strategy for building mutually beneficial relationships, I'd say "don't profit off my losses". I want a partner like relationship, but the only thing anyone is currently offering is for me to be a customer. I have to make all the predictions on conversion rates, etc., so I'm taking all the risk while the platform owner (ie: you) makes a (high-margin) profit off every user I have, regardless of whether or not I'm generating revenue from that user. > for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high I would say it makes sense to bucket users into categories and split the feature set accordingly. I think that's what Firebase does [1A]. I think basic login types (magic links, password, social) are free and you only pay for users that need their identity platform. However, there are a few problems with Firebase IMO. First, I don't like "free". It means my costs aren't realistic and I need to assess the risk of that offering disappearing. IMHO that's just another layer of complexity and risk and I'd rather pay fair value from the start. The second problem with Firebase is that it's going to take a decade of culture change at Google for me to trust any of their products, especially something that's "free". Back to Supabase, what do you do if you want to add a significant feature that makes the current auth pricing unsustainable? Do you increase the price a tiny bit? What if I have a million free users and don't need that feature for them? > and we're an order of magnitude cheaper than other Auth providers This is a little unfair on my part because I don't know the true costs, but if that means you're only charging me 100x the underlying costs vs everyone else charging 1000x, that doesn't make it good value for me, does it? I'd rather categorize my users and pay accordingly. I know this may not be realistic in terms of creating too many SKUs, but just to make the point (from my perspective)... 1. Free users get magic links. Pricing should be tied to real costs and be commodity like. Minimal cost (to me) is important. Long term, stable, predictable pricing is important. This comes out of my pocket, so I don't want you having a large margin on it and I don't want it fluctuating because small changes can have a large impact on me if I have a lot of free users. 2. Convertible users get passwords, social logins, TOTP, security keys, etc.. Basically they get anything that doesn't have external costs (to you). I'd be willing to subsidize these a bit, but not anything crazy. 3. Paying users get SMS, etc.. Basically they get things that have external costs (to you). I'd pay a large premium for these users and I'd be willing to take on all the external costs in addition to that premium (ex: I pay for all SMS costs). 4. B2B users get any B2B features and my (inexperienced) opinion is they fall into a category where the cost (to me) doesn't matter much. The other thing that I don't like about having a uniform cost per user is that I know the cost per user isn't uniform and, if my costs aren't a function of your costs, that means you're taking on some risk in the prices you've set. What if your overall prices are too low even though my specific usage is already profitable? Do I have to endure a price increase? Again, this is uninformed because I don't have a decent knowledge of the true costs, but for my use case (magic links only, bring your own email) the prices feel 100x too expensive, but for a B2B use case they feel 100x too cheap. I'm sure it's difficult to accommodate all use cases in a way that makes everyone happy, so hopefully my perspective is useful feedback. 1A. https://github.com/255kb/stack-on-a-budget/blob/master/pages/user-authentication.md#firebase-authentication https://github.com/255kb/stack-on-a-budget/blob/master/pages...

by ryan29 3y ago

kiwicopple 3y ago

> Is it 4 auth related emails per hour by default? It's unlimited emails per hour, as long as you BYO SMTP provider. The default email service is only for testing, and not recommended for production. I usually recommen AWS SES or Resend[0] for unlimited emails > This isn't just a Supabase issue either. The entire auth industry is similar. Agreed - the industry prices on MAU, which isn't a great heuristic. for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high. For Supabase, we simply try to be fair and transparent (and we're an order of magnitude cheaper than other Auth providers). There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc. [0] https://resend.com/docs/send-with-supabase-smtp https://resend.com/docs/send-with-supabase-smtp

ryan29 3y ago
> There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc. Yeah. I was hesitant to toss examples of actual costs in there because I knew it wasn't really a fair comparison, but I wanted to try to make my point even though I don't have the ability to calculate the real costs. If I had to sum it up in a way that translates into a good strategy for building mutually beneficial relationships, I'd say "don't profit off my losses". I want a partner like relationship, but the only thing anyone is currently offering is for me to be a customer. I have to make all the predictions on conversion rates, etc., so I'm taking all the risk while the platform owner (ie: you) makes a (high-margin) profit off every user I have, regardless of whether or not I'm generating revenue from that user. > for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high I would say it makes sense to bucket users into categories and split the feature set accordingly. I think that's what Firebase does [1A]. I think basic login types (magic links, password, social) are free and you only pay for users that need their identity platform. However, there are a few problems with Firebase IMO. First, I don't like "free". It means my costs aren't realistic and I need to assess the risk of that offering disappearing. IMHO that's just another layer of complexity and risk and I'd rather pay fair value from the start. The second problem with Firebase is that it's going to take a decade of culture change at Google for me to trust any of their products, especially something that's "free". Back to Supabase, what do you do if you want to add a significant feature that makes the current auth pricing unsustainable? Do you increase the price a tiny bit? What if I have a million free users and don't need that feature for them? > and we're an order of magnitude cheaper than other Auth providers This is a little unfair on my part because I don't know the true costs, but if that means you're only charging me 100x the underlying costs vs everyone else charging 1000x, that doesn't make it good value for me, does it? I'd rather categorize my users and pay accordingly. I know this may not be realistic in terms of creating too many SKUs, but just to make the point (from my perspective)... 1. Free users get magic links. Pricing should be tied to real costs and be commodity like. Minimal cost (to me) is important. Long term, stable, predictable pricing is important. This comes out of my pocket, so I don't want you having a large margin on it and I don't want it fluctuating because small changes can have a large impact on me if I have a lot of free users. 2. Convertible users get passwords, social logins, TOTP, security keys, etc.. Basically they get anything that doesn't have external costs (to you). I'd be willing to subsidize these a bit, but not anything crazy. 3. Paying users get SMS, etc.. Basically they get things that have external costs (to you). I'd pay a large premium for these users and I'd be willing to take on all the external costs in addition to that premium (ex: I pay for all SMS costs). 4. B2B users get any B2B features and my (inexperienced) opinion is they fall into a category where the cost (to me) doesn't matter much. The other thing that I don't like about having a uniform cost per user is that I know the cost per user isn't uniform and, if my costs aren't a function of your costs, that means you're taking on some risk in the prices you've set. What if your overall prices are too low even though my specific usage is already profitable? Do I have to endure a price increase? Again, this is uninformed because I don't have a decent knowledge of the true costs, but for my use case (magic links only, bring your own email) the prices feel 100x too expensive, but for a B2B use case they feel 100x too cheap. I'm sure it's difficult to accommodate all use cases in a way that makes everyone happy, so hopefully my perspective is useful feedback. 1A. https://github.com/255kb/stack-on-a-budget/blob/master/pages/user-authentication.md#firebase-authentication https://github.com/255kb/stack-on-a-budget/blob/master/pages...