6 ms·

hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on

hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread today’s launch delivers on many of those promises. We’ve added better support for database migrations, seeding, backups, debugging, and documentation. we have a lot of work ahead, this is just the first step. our next major step forward is “branching”, which we’re rolling out today for development partners and alpha testers. we’ve coupled the branching functionality to GitHub for now. whenever you create a new PR we launch a new instance, run the database migrations in your version control, and seed the database for reproducible test environments. we’re using Firecracker[1] for every preview environment. This environment automatically pauses when it’s not in use. we’re seeing some very impressive startup times, even though we’re stuffing a lot of services inside the VM. We looked at making full-production clones but decided against that for now until we have a robust strategy for anonymizing production data and mocking out calls to external services. Ultimately we want to offer both options, it’s just easier and safer to start with seed data. since supabase offers a few services beyond the Postgres database, we still have a few questions to work through with our alpha testers. for example, we also store images/videos/files for our customers. Do these need to be anonymized in preview environments? we don’t have all the answers yet, but we’re moving in the right direction. As hard as it was to have a customer migrate away so publicly, I’m proud of the work the team have done to improve on feedback [0] https://news.ycombinator.com/item?id=36006018 https://news.ycombinator.com/item?id=36006018 [1] Firecracker: https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/

CSSer 3y ago
Thank you so much for taking the initiative to learn and grow from that experience. My team is in the fledging stages of using Supabase to rebuild a mission-critical application for our company. We were initially disappointed with what we found in terms of CI/CD and local development but we liked Supabase enough for other reasons to keep moving forward with it. I'm really glad we did because I think this has the potential to be a major boon for the productivity and efficiency of building and maintaining our project over time. I get the impression that you're making really good calls as it relates to your roadmap, and I'm really looking forward to exploring these workflows and sharing what I find with my team. Thanks again!
- kiwicopple 3y ago
  > I get the impression that you're making really good calls as it relates to your roadmap we receive feedback from a lot of channels so it's often hard to figure out what to build. In the early days it was about reaching feature-parity with other tools. now we have a bit more breathing-room to focus on "day 2" problems. I think our team is excited about this phase since it means we get an opportunity to build something new/innovative
  - fjfuvucucuc 3y ago
    [dead]
swyx 3y ago
really impressive how you responded to that criticism - listening to feedback and then building out a full product suite. looking forward to try out everything here, particularly branching, because just yesterday i was looking thru the docs recommending staging/dev/prod instances and wondering if there was a better way!
jadbox 3y ago
After being burned by other DaaS providers (looking at you AWS Amplify/Cognito), I've been skeptical to use anything other than rolling my own solutions. Supabase updates does continue to impress, and I do really appreciate these improvements to local development.
- deleted 3y ago
  [deleted]
- kiwicopple 3y ago
  > rolling my own solutions I would love to hear what solutions you're choosing. one of our goals is to provide only the tools/tech/features that you'd choose yourself or need to build to get started. If you're skeptical based on our technology choices then it's useful to receive that feedback
  - 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...
fosterfriends 3y ago
Love the candor and follow-up on community feedback! Sounds like y'all are working hard, keep it up :)
nathancahill 3y ago
Massive congrats on shipping this. Will really improve the DevEx. Are you hiring?
- kiwicopple 3y ago
  I don't think we have any positions open currently unfortunately, although we're always looking for talented SREs & support to keep up with the platform growth. feel free to reach out (my details are in my profile)
thewataccount 3y ago
I checked a little bit ago but I might have missed it so please correct me. Are there plans to expand self-hosting support? The migrations are a big step forward. Are you intending to fill the roll of being a framework akin to a "super django" type of deal? Again the migrations help a ton, but I've been hesitant to use Supabase for random projects because I don't want to rely on the platform, and I don't want random people on github who want to try or contribute to require a supabase account. I'd love to use it more as a modular ORM for miscellaneous projects instead of the current "hosted platform", currently none of the tutorials (or github projects) seem to explain this route at all. I think you actually do work for this purpose, and I think the docs mostly cover the bare minimum for self hosting, and I understand your business kinda relies on the hosted platform, but I'd love to see further tutorials and thorough explinations of all the features - currently some like the AI features aren't really explained if they work in the self-hosted or not, or if you have to do anything special for that. EDIT: Also I do appreciate your business being opensource, and contributing to postgres so much! Sorry for the rambling, and I apologize if I'm blind and missed some obvious docs.
- kiwicopple 3y ago
  > Are you intending to fill the roll of being a framework akin to a "super django" type of deal? We don't plan to replace any specific framework. We simply want to make Postgres easier to use. You can use Django (or any other framework) and Supabase together. We provide some additional tooling on top, but we aim to make this tooling 100% compatible with other tools. As an example, here[1] is a change we made recently so that our Storage service works better with Clerk (a popular Auth service, which is a good alternative to our own Auth service). We plan to document this better - it was one of the promises I made in the OP. > Are there plans to expand self-hosting support? we made a few updates[0] this week to improve self-hosting based on the common feedback. if there is anything missing just let me know and i will do another round of improvements. > currently some like the AI features aren't really explained if they work in the self-hosted or not, or if you have to do anything special for that. nothing is feature-gated so everything works on self-hosted. That said, I agree that we can be better at explaining the self-hosting. We are putting a lot more effort into improving our docs in general. For self-hosting we can certainly be clearer about the boundaries where you are responsible (eg, you need to take care of your own backups, the AI features will require external acconts). we're working on this, but feel free to open issues where it's unclear we can address anything specific [0] https://github.com/supabase/supabase/pull/16097 https://github.com/supabase/supabase/pull/16097 [1] https://github.com/supabase/storage-api/pull/340 https://github.com/supabase/storage-api/pull/340
soultrees 3y ago
Respect. This is how you build a winning product and make your users feel heard. Take note upcoming class.
fulafel 3y ago
In the original posting from Val Town I didn't quite catch why in lieu of local dev they did't use dedicated dev dbs (possibly per developer) in the Supabase service. Anyone have perspectives on pros and cons of local dev vs cloud dev environments with Supabase?
deleted 3y ago
[deleted]

CSSer 3y ago

Thank you so much for taking the initiative to learn and grow from that experience. My team is in the fledging stages of using Supabase to rebuild a mission-critical application for our company. We were initially disappointed with what we found in terms of CI/CD and local development but we liked Supabase enough for other reasons to keep moving forward with it. I'm really glad we did because I think this has the potential to be a major boon for the productivity and efficiency of building and maintaining our project over time. I get the impression that you're making really good calls as it relates to your roadmap, and I'm really looking forward to exploring these workflows and sharing what I find with my team. Thanks again!

kiwicopple 3y ago
> I get the impression that you're making really good calls as it relates to your roadmap we receive feedback from a lot of channels so it's often hard to figure out what to build. In the early days it was about reaching feature-parity with other tools. now we have a bit more breathing-room to focus on "day 2" problems. I think our team is excited about this phase since it means we get an opportunity to build something new/innovative
- fjfuvucucuc 3y ago
  [dead]

swyx 3y ago

really impressive how you responded to that criticism - listening to feedback and then building out a full product suite. looking forward to try out everything here, particularly branching, because just yesterday i was looking thru the docs recommending staging/dev/prod instances and wondering if there was a better way!

jadbox 3y ago

After being burned by other DaaS providers (looking at you AWS Amplify/Cognito), I've been skeptical to use anything other than rolling my own solutions. Supabase updates does continue to impress, and I do really appreciate these improvements to local development.

deleted 3y ago
[deleted]
kiwicopple 3y ago
> rolling my own solutions I would love to hear what solutions you're choosing. one of our goals is to provide only the tools/tech/features that you'd choose yourself or need to build to get started. If you're skeptical based on our technology choices then it's useful to receive that feedback
- 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...

fosterfriends 3y ago

Love the candor and follow-up on community feedback! Sounds like y'all are working hard, keep it up :)

nathancahill 3y ago

Massive congrats on shipping this. Will really improve the DevEx. Are you hiring?

kiwicopple 3y ago
I don't think we have any positions open currently unfortunately, although we're always looking for talented SREs & support to keep up with the platform growth. feel free to reach out (my details are in my profile)

thewataccount 3y ago

I checked a little bit ago but I might have missed it so please correct me. Are there plans to expand self-hosting support? The migrations are a big step forward. Are you intending to fill the roll of being a framework akin to a "super django" type of deal? Again the migrations help a ton, but I've been hesitant to use Supabase for random projects because I don't want to rely on the platform, and I don't want random people on github who want to try or contribute to require a supabase account. I'd love to use it more as a modular ORM for miscellaneous projects instead of the current "hosted platform", currently none of the tutorials (or github projects) seem to explain this route at all. I think you actually do work for this purpose, and I think the docs mostly cover the bare minimum for self hosting, and I understand your business kinda relies on the hosted platform, but I'd love to see further tutorials and thorough explinations of all the features - currently some like the AI features aren't really explained if they work in the self-hosted or not, or if you have to do anything special for that. EDIT: Also I do appreciate your business being opensource, and contributing to postgres so much! Sorry for the rambling, and I apologize if I'm blind and missed some obvious docs.

kiwicopple 3y ago
> Are you intending to fill the roll of being a framework akin to a "super django" type of deal? We don't plan to replace any specific framework. We simply want to make Postgres easier to use. You can use Django (or any other framework) and Supabase together. We provide some additional tooling on top, but we aim to make this tooling 100% compatible with other tools. As an example, here[1] is a change we made recently so that our Storage service works better with Clerk (a popular Auth service, which is a good alternative to our own Auth service). We plan to document this better - it was one of the promises I made in the OP. > Are there plans to expand self-hosting support? we made a few updates[0] this week to improve self-hosting based on the common feedback. if there is anything missing just let me know and i will do another round of improvements. > currently some like the AI features aren't really explained if they work in the self-hosted or not, or if you have to do anything special for that. nothing is feature-gated so everything works on self-hosted. That said, I agree that we can be better at explaining the self-hosting. We are putting a lot more effort into improving our docs in general. For self-hosting we can certainly be clearer about the boundaries where you are responsible (eg, you need to take care of your own backups, the AI features will require external acconts). we're working on this, but feel free to open issues where it's unclear we can address anything specific [0] https://github.com/supabase/supabase/pull/16097 https://github.com/supabase/supabase/pull/16097 [1] https://github.com/supabase/storage-api/pull/340 https://github.com/supabase/storage-api/pull/340

soultrees 3y ago

Respect. This is how you build a winning product and make your users feel heard. Take note upcoming class.

fulafel 3y ago

In the original posting from Val Town I didn't quite catch why in lieu of local dev they did't use dedicated dev dbs (possibly per developer) in the Supabase service. Anyone have perspectives on pros and cons of local dev vs cloud dev environments with Supabase?

deleted 3y ago

[deleted]