10 ms·

Storage is now available in Supabase (YC S20)

194 points by kiwicopple 6y ago

colesantiago 6y ago
Is there any bandwidth restrictions here using Supabase's storage?
- swyx 6y ago
  ah, very key. i'd highlight Werner Vogels' recent interview here on lessons learned from setting up S3 itself: https://cacm.acm.org/magazines/2021/3/250706-a-second-conversation-with-werner-vogels/fulltext https://cacm.acm.org/magazines/2021/3/250706-a-second-conver... "Here is another interesting example with S3. It's probably the only time we changed our pricing strategy. When we launched S3, we were charging only for data transfer and data storage. It turned out that we had quite a few customers who were storing millions and millions of thumbnails of products they were selling on eBay. There was not much storage because these thumbnails were really small, and there wasn't much data transfer either, but there were enormous numbers of requests. It made us learn, for example, when you design interfaces, and definitely those you charge for, you want to charge for what is driving your own cost. One of the costs that we didn't anticipate was the number of requests, and request handling. We added this later to the payment model in S3, but it was clearly something we didn't anticipate. Services that came after S3 have been able to learn the lessons from S3 itself."
- kiwicopple 6y ago
  There are no restrictions, however we just released our [Pricing](https://supabase.io/pricing https://supabase.io/pricing) yesterday. TLDR: for the free tier there is a limit of 1GB storage, and 2GB egress/month, pro tier: 100GB storage, and 200 egress/month, and after that it's Pay as you Go.
  - inian 6y ago
    After we finish integrating Storage with a CDN, the price / GB for egress traffic will be even lower.
- deleted 6y ago
  [deleted]
kiwicopple 6y ago
Hey HN, Supabase is an open source Firebase alternative. We're building the features of Firebase using enterprise-grade open source tools. We're particularly focused on scalability. We take proven tools like Postgres, and we make them as easy to use as Firebase. Today Supabase is releasing Storage. This is our second launch of Launch Week[1]. The linked blog post goes into depth around the technical implementation, so I’ll just give a recap for the people who jump straight to comments (like me). Backend: We are using S3 as a File store. Since most storage platforms have an S3-compatible API, this made the most sense. We will add more providers (like Backblaze) in the future. Middleware: This is the key part. We assessed a lot of tools including Ceph, Swift, Minio and Zenko. These are all awesome, but they aren’t tightly integrated with Postgres. The tooling in Supabase is centered around Postgres: the APIs use PostgREST[2], the Realtime engine hooks into Postgres’ WAL[3] and we use GoTrue[4] + Postgres Row Level Security[5] for Auth. Since we already use RLS for Auth, we decided to leverage the same functionality for managing access to Files. We created an API [6] which wraps everything up into a nice interface. This obviously goes against our philosophy of “support existing tools” - the linked blog post describes our rationale more thoroughly. Future: This is very much an “alpha” release of Storage. We have a lot of great features planned for a CDN, automatic resizing, optimizations, and since it’s using Postgres there potentially are a few neat things we can do with Full Text Search and Data Loading. A few of the team will be here to answer any questions - my cofounder @awalias and @steve-chavez from PostgREST, @inian, and @1_over_n [1] Launch week: https://supabase.io/new/blog/2021/03/25/launch-week https://supabase.io/new/blog/2021/03/25/launch-week [2] PostgREST: http://postgrest.org/ http://postgrest.org/ [3] Realtime: https://github.com/supabase/realtime https://github.com/supabase/realtime [4] GoTrue: https://github.com/supabase/supabase/tree/master/docker https://github.com/supabase/supabase/tree/master/docker [5] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [6] Storage API: https://github.com/supabase/storage-api https://github.com/supabase/storage-api
inian 6y ago
A shoutout to Fastify[1] here. It has lived up to its claim of being one of the fastest Node frameworks from our initial benchmarking. We plan to add the benchmarking scripts to our benchmarking repo[2] soon. The entire Fastify ecosystem (and associated modules like pino) has a focus on performance which is great. For example, the file-handling middleware[3] uses Node streams by default, instead of buffering files in memory. This made it easy to use streams across our entire codebase. Besides performance, this keeps the footprint small which ensures consistent performance even for users on our smallest server configuration. [1] https://www.fastify.io/ https://www.fastify.io/ [2] https://github.com/supabase/benchmarks https://github.com/supabase/benchmarks [3] https://github.com/fastify/fastify-multipart https://github.com/fastify/fastify-multipart
swyx 6y ago
congrats gang! this is a huge release and its only Tuesday. one step further toward becoming a full Open Source Firebase™. as a frontend dev i was naturally drawn to the Frontend piece of this launch - doing both columns and lists and rich previews is very thoughtful! makes it a joy to use. you've probably thought about this but i didnt see it addressed in the blogpost or docs - i'd love for TTL or soft deletes to be built in to the Storage API. i could of course model that myself with a backing table and some scheduled functions but... it'd be nice to just have it built in :)
- kiwicopple 6y ago
  Thanks. The front end was an area which we knew we could improve over existing services. Simple actions like multi-folder selects/deletes are impossible with most services. Miller columns are an easy solution to this. We still have a long way to go on the UI - command bars, keyboard navigation, and accessibility are still getting built. > TTL or soft deletes This is a great idea, and won't be a problem (adding some dates into the Postgres schema). I'll make sure it's on the roadmap for the team to discuss
  - swyx 6y ago
    TIL about Miller columns... https://en.wikipedia.org/wiki/Miller_columns https://en.wikipedia.org/wiki/Miller_columns cool name drop! i see now its in the blogpost but i missed it in the initial read
mateomorris 6y ago
Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.
- kiwicopple 6y ago
  wow, that's a glowing recommendation. Thanks for the kind words. We have a long way to go to catch up with Firebase on most features, but of course we are benefiting from all the hard work that other OSS tools have already delivered. Postgres does most of the heavy-lifting, PostgREST is amazing, and Netlify's GoTrue server is a key piece of our architecture.
  - eloff 6y ago
    I'm curious about GoTrue, isn't that MySQL only? So do you guys run MySQL for the users database, or?
    - kiwicopple 6y ago
      We run a fork of GoTrue, using the migrations in this PR: https://github.com/netlify/gotrue/pull/254 https://github.com/netlify/gotrue/pull/254 tbh, our fork[1] has deviated a bit from Netlify's so we need to spend some time with them upstream'ing any changes that they would want to merge (perhaps magic links, Azure logins, OAuth scopes). Long term, I think we will need to run 2 different forks because we have different requirements for multi-tenant. So the benefit here would be sharing "OAuth providers" (eg, if we add Okta, we upstream it, if they add Twitter logins, we pull it) [1] https://github.com/supabase/gotrue https://github.com/supabase/gotrue
- benatkin 6y ago
  > Even if it wasn’t open source it would still be a better alternative. Well, it's not hard to imagine that, since they don't provide a way to self-host it.
patrickaljord 6y ago
Quick feedback from your frontpage, the slack demo does not work when trying to sign up https://supabase-slack-clone-supabase.vercel.app/ https://supabase-slack-clone-supabase.vercel.app/
- 1_over_n 6y ago
  Sorry, we will get that fixed over the next couple of days! p.s thanks for the heads up
iyn 6y ago
Congrats on the launch! I like how you approached adding Storage to the product/platform?, keeping the initial version minimal, yet polished. I've been following you since the public launch and I'm really impressed by your work and progress. Definitely keeping an eye as you go, Supbase is a tool that could fit really nicely in the projects I'm usually working on (fullstack web, mobile apps). I wonder what's your perspective on the GraphQL (and Prisma)? I'm asking, since currently I'm working on a project using Redwood.js, with Prisma on the API layer. Prisma helps a lot with my productivity, as my data model is quite complex, with many relationships/nested queries (read heavy). For the same reason, GraphQL increases my speed on the frontend, since there's just 1 query for nested reads and I don't have to play a requests orchestration game (been there before and it's really slowing down development, at least in my experience). The problem with my current project/setup is that auth, storage, realtime and queues/workers parts are... not ideal and fragmented, as I need to use different providers/servers for each (Auth0, Pusher, dealing with S3 integration, separate server for a worker, since redwood is serverless-first). Focusing on auth, I'm not really satisfied with Auth0 and would love to use something else but only if the migration effort would be worth it. And Supbase looks like something that would make the migration worthwhile, as it solves multiple of my pain points. That's the context behind GraphQL/Prisma question -- right now you're REST-first (which is totally fine, don't want any flamewars REST vs GQL) and I wonder how would that fit in my project, which is very Prisma dependent, with 100% GraphQL API. I have some vague ideas but would love to hear your thoughts here and how you think about GraphQL/Prisma + Supbase mid/long term. Thanks.
- kiwicopple 6y ago
  We're quite close to the Redwood team - the community there are awesome. > what's your perspective on the GraphQL (and Prisma)? Every Supabase project is a full Postgres instance, so you can connect Prisma to it (we provide the Postgres connection string in the Project Settings). There is a potential issue if you are using serverless functions with Postgres (because connections are expensive in Postgres), but look out for an announcement soon which will solve this ... > I'm not really satisfied with Auth0 and would love to use something else You can also choose to use a single part of Supabase (just the Auth). I'm biased, but I think we are a lot simpler to use. We have a long way to go to catch up to their enterprise offerings though (compliance, SOC2, etc).
orangefarm 6y ago
Congrats to the launch! Very impressed with the progress :) Do you have plans to add passwordless auth (either magic link or OTP - preferably OTP)?
- kiwicopple 6y ago
  Thanks! > magic link We have this one available here: https://supabase.io/docs/reference/javascript/auth-signin#sign-in-with-magic-link https://supabase.io/docs/reference/javascript/auth-signin#si... We don't have OTP, but that's a great idea - something we can add to GoTrue (https://github.com/supabase/gotrue https://github.com/supabase/gotrue)
rajatsx 6y ago
Why is Supabase as costly as Firebase? Why would I go for a service that's in beta and charges as much as a stable competitor?
yclurker 6y ago
Supabase is NOT open source and it's Founders are highly unethical. Here’s why. We heavily rely both on postgres and Firebase. And when Supabase came as an “open source” Firebase alternative (also a YC company), naturally we were excited. However ever since the launch, time and again the community has kept asking for a self-hostable version to no avail. And community is requesting that since not all of Supabase is open source. If it were, community themselves would have built it. But Founders have been “milking” the words “Open Source” and ignoring the community altogether. Here is the full story : Few weeks ago, I checked supabase self hosting documentation again ==> they were callous enough to even mention how to move away from Supabase and had no instructions to self host! Completely put off by this unethical means of taking community and words open source for granted, I prompted them about it. And their response has been to remove “How to Self host” section altogether from the website, documentation and Github. And then provided a fully watered down version of docker-compose which “is barely functional or useful” to community as it has no dashboard within it. Whenever self hostable questions comes up, Supabase Founders cover up by providing vague answers like ==> “We are building with existing & proven OSS tools. We stitch them all together seamlessly”. When decrypted, that translates to ==> “We use open source to build our software (hey nothing special here : bazillion companies do that). There will never be a usable self-hostable solution in near future”. F** you Supabase. Every single open source company that I can think of can be self-hosted. World class open source companies go to great lengths to ensure its always self hostable even by compiling source. Supabase founders : You should be so ashamed of yourself for setting such low standards on what could be termed as open source.
- harporoeder 6y ago
  I am a little confused by your description. I do not use Supabase but the source appears to be available on github and is actively updated. Are you claiming that because they do not provide clear documentation on how to self host they are not open source? Perhaps a good Samaritan could read through the repository and write some basic documentation which is enabled by virtue of being open source.
  - yclurker 6y ago
patatino 6y ago
Can I ditch uploadcare and use supabase storage when "CDN integration" and "Auto transformation & optimisation" are ready? Or does is not compare?
- inian 6y ago
  Yes, it is comparable. We will support all the basic transformations like resize, crop, rotate, etc. Advanced transformations like object detection is not in the immediate roadmap, unless there is demand for it. In terms of asset optimization, we are planning to go all out though. What features of Uploadcare are you using?
  - patatino 6y ago
    I do not need advanced transformations, just basic image uploading and displaying on my websites. The best feature for me is the react widget which I can quickly drop into my project and just be done with uploading. Maybe that would be a great feature in the supabase/ui project in the future.
robertlacok 6y ago
Hey, cool product! I'm curious - I saw you use Auth0 for your hosted solution, even though your own platform offers auth. Do you plan to use Supabase for Supabase?
- kiwicopple 6y ago
  Yes, definitely. When we launched Supabase we didn't have Auth which is why we use Auth0. Migrating has been in the backlog for a few months now. Now that we have shipped Storage, we should have a bit more time!
macklemoreshair 6y ago
Not impressed so far. We use firebase and would never consider moving over to this in its current state. Why would I pay for some hack on top of Postgres?

194 points by kiwicopple 6y ago

colesantiago 6y ago

Is there any bandwidth restrictions here using Supabase's storage?

swyx 6y ago
ah, very key. i'd highlight Werner Vogels' recent interview here on lessons learned from setting up S3 itself: https://cacm.acm.org/magazines/2021/3/250706-a-second-conversation-with-werner-vogels/fulltext https://cacm.acm.org/magazines/2021/3/250706-a-second-conver... "Here is another interesting example with S3. It's probably the only time we changed our pricing strategy. When we launched S3, we were charging only for data transfer and data storage. It turned out that we had quite a few customers who were storing millions and millions of thumbnails of products they were selling on eBay. There was not much storage because these thumbnails were really small, and there wasn't much data transfer either, but there were enormous numbers of requests. It made us learn, for example, when you design interfaces, and definitely those you charge for, you want to charge for what is driving your own cost. One of the costs that we didn't anticipate was the number of requests, and request handling. We added this later to the payment model in S3, but it was clearly something we didn't anticipate. Services that came after S3 have been able to learn the lessons from S3 itself."
kiwicopple 6y ago
There are no restrictions, however we just released our [Pricing](https://supabase.io/pricing https://supabase.io/pricing) yesterday. TLDR: for the free tier there is a limit of 1GB storage, and 2GB egress/month, pro tier: 100GB storage, and 200 egress/month, and after that it's Pay as you Go.
- inian 6y ago
  After we finish integrating Storage with a CDN, the price / GB for egress traffic will be even lower.
deleted 6y ago
[deleted]

kiwicopple 6y ago

Hey HN, Supabase is an open source Firebase alternative. We're building the features of Firebase using enterprise-grade open source tools. We're particularly focused on scalability. We take proven tools like Postgres, and we make them as easy to use as Firebase. Today Supabase is releasing Storage. This is our second launch of Launch Week[1]. The linked blog post goes into depth around the technical implementation, so I’ll just give a recap for the people who jump straight to comments (like me). Backend: We are using S3 as a File store. Since most storage platforms have an S3-compatible API, this made the most sense. We will add more providers (like Backblaze) in the future. Middleware: This is the key part. We assessed a lot of tools including Ceph, Swift, Minio and Zenko. These are all awesome, but they aren’t tightly integrated with Postgres. The tooling in Supabase is centered around Postgres: the APIs use PostgREST[2], the Realtime engine hooks into Postgres’ WAL[3] and we use GoTrue[4] + Postgres Row Level Security[5] for Auth. Since we already use RLS for Auth, we decided to leverage the same functionality for managing access to Files. We created an API [6] which wraps everything up into a nice interface. This obviously goes against our philosophy of “support existing tools” - the linked blog post describes our rationale more thoroughly. Future: This is very much an “alpha” release of Storage. We have a lot of great features planned for a CDN, automatic resizing, optimizations, and since it’s using Postgres there potentially are a few neat things we can do with Full Text Search and Data Loading. A few of the team will be here to answer any questions - my cofounder @awalias and @steve-chavez from PostgREST, @inian, and @1_over_n [1] Launch week: https://supabase.io/new/blog/2021/03/25/launch-week https://supabase.io/new/blog/2021/03/25/launch-week [2] PostgREST: http://postgrest.org/ http://postgrest.org/ [3] Realtime: https://github.com/supabase/realtime https://github.com/supabase/realtime [4] GoTrue: https://github.com/supabase/supabase/tree/master/docker https://github.com/supabase/supabase/tree/master/docker [5] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [6] Storage API: https://github.com/supabase/storage-api https://github.com/supabase/storage-api

inian 6y ago

A shoutout to Fastify[1] here. It has lived up to its claim of being one of the fastest Node frameworks from our initial benchmarking. We plan to add the benchmarking scripts to our benchmarking repo[2] soon. The entire Fastify ecosystem (and associated modules like pino) has a focus on performance which is great. For example, the file-handling middleware[3] uses Node streams by default, instead of buffering files in memory. This made it easy to use streams across our entire codebase. Besides performance, this keeps the footprint small which ensures consistent performance even for users on our smallest server configuration. [1] https://www.fastify.io/ https://www.fastify.io/ [2] https://github.com/supabase/benchmarks https://github.com/supabase/benchmarks [3] https://github.com/fastify/fastify-multipart https://github.com/fastify/fastify-multipart

swyx 6y ago

congrats gang! this is a huge release and its only Tuesday. one step further toward becoming a full Open Source Firebase™. as a frontend dev i was naturally drawn to the Frontend piece of this launch - doing both columns and lists and rich previews is very thoughtful! makes it a joy to use. you've probably thought about this but i didnt see it addressed in the blogpost or docs - i'd love for TTL or soft deletes to be built in to the Storage API. i could of course model that myself with a backing table and some scheduled functions but... it'd be nice to just have it built in :)

kiwicopple 6y ago
Thanks. The front end was an area which we knew we could improve over existing services. Simple actions like multi-folder selects/deletes are impossible with most services. Miller columns are an easy solution to this. We still have a long way to go on the UI - command bars, keyboard navigation, and accessibility are still getting built. > TTL or soft deletes This is a great idea, and won't be a problem (adding some dates into the Postgres schema). I'll make sure it's on the roadmap for the team to discuss
- swyx 6y ago
  TIL about Miller columns... https://en.wikipedia.org/wiki/Miller_columns https://en.wikipedia.org/wiki/Miller_columns cool name drop! i see now its in the blogpost but i missed it in the initial read

mateomorris 6y ago

Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.

kiwicopple 6y ago
wow, that's a glowing recommendation. Thanks for the kind words. We have a long way to go to catch up with Firebase on most features, but of course we are benefiting from all the hard work that other OSS tools have already delivered. Postgres does most of the heavy-lifting, PostgREST is amazing, and Netlify's GoTrue server is a key piece of our architecture.
- eloff 6y ago
  I'm curious about GoTrue, isn't that MySQL only? So do you guys run MySQL for the users database, or?
  - kiwicopple 6y ago
    We run a fork of GoTrue, using the migrations in this PR: https://github.com/netlify/gotrue/pull/254 https://github.com/netlify/gotrue/pull/254 tbh, our fork[1] has deviated a bit from Netlify's so we need to spend some time with them upstream'ing any changes that they would want to merge (perhaps magic links, Azure logins, OAuth scopes). Long term, I think we will need to run 2 different forks because we have different requirements for multi-tenant. So the benefit here would be sharing "OAuth providers" (eg, if we add Okta, we upstream it, if they add Twitter logins, we pull it) [1] https://github.com/supabase/gotrue https://github.com/supabase/gotrue
benatkin 6y ago
> Even if it wasn’t open source it would still be a better alternative. Well, it's not hard to imagine that, since they don't provide a way to self-host it.

patrickaljord 6y ago

Quick feedback from your frontpage, the slack demo does not work when trying to sign up https://supabase-slack-clone-supabase.vercel.app/ https://supabase-slack-clone-supabase.vercel.app/

1_over_n 6y ago
Sorry, we will get that fixed over the next couple of days! p.s thanks for the heads up

iyn 6y ago

Congrats on the launch! I like how you approached adding Storage to the product/platform?, keeping the initial version minimal, yet polished. I've been following you since the public launch and I'm really impressed by your work and progress. Definitely keeping an eye as you go, Supbase is a tool that could fit really nicely in the projects I'm usually working on (fullstack web, mobile apps). I wonder what's your perspective on the GraphQL (and Prisma)? I'm asking, since currently I'm working on a project using Redwood.js, with Prisma on the API layer. Prisma helps a lot with my productivity, as my data model is quite complex, with many relationships/nested queries (read heavy). For the same reason, GraphQL increases my speed on the frontend, since there's just 1 query for nested reads and I don't have to play a requests orchestration game (been there before and it's really slowing down development, at least in my experience). The problem with my current project/setup is that auth, storage, realtime and queues/workers parts are... not ideal and fragmented, as I need to use different providers/servers for each (Auth0, Pusher, dealing with S3 integration, separate server for a worker, since redwood is serverless-first). Focusing on auth, I'm not really satisfied with Auth0 and would love to use something else but only if the migration effort would be worth it. And Supbase looks like something that would make the migration worthwhile, as it solves multiple of my pain points. That's the context behind GraphQL/Prisma question -- right now you're REST-first (which is totally fine, don't want any flamewars REST vs GQL) and I wonder how would that fit in my project, which is very Prisma dependent, with 100% GraphQL API. I have some vague ideas but would love to hear your thoughts here and how you think about GraphQL/Prisma + Supbase mid/long term. Thanks.

kiwicopple 6y ago
We're quite close to the Redwood team - the community there are awesome. > what's your perspective on the GraphQL (and Prisma)? Every Supabase project is a full Postgres instance, so you can connect Prisma to it (we provide the Postgres connection string in the Project Settings). There is a potential issue if you are using serverless functions with Postgres (because connections are expensive in Postgres), but look out for an announcement soon which will solve this ... > I'm not really satisfied with Auth0 and would love to use something else You can also choose to use a single part of Supabase (just the Auth). I'm biased, but I think we are a lot simpler to use. We have a long way to go to catch up to their enterprise offerings though (compliance, SOC2, etc).

orangefarm 6y ago

Congrats to the launch! Very impressed with the progress :) Do you have plans to add passwordless auth (either magic link or OTP - preferably OTP)?

kiwicopple 6y ago
Thanks! > magic link We have this one available here: https://supabase.io/docs/reference/javascript/auth-signin#sign-in-with-magic-link https://supabase.io/docs/reference/javascript/auth-signin#si... We don't have OTP, but that's a great idea - something we can add to GoTrue (https://github.com/supabase/gotrue https://github.com/supabase/gotrue)

rajatsx 6y ago

Why is Supabase as costly as Firebase? Why would I go for a service that's in beta and charges as much as a stable competitor?

yclurker 6y ago

Supabase is NOT open source and it's Founders are highly unethical. Here’s why. We heavily rely both on postgres and Firebase. And when Supabase came as an “open source” Firebase alternative (also a YC company), naturally we were excited. However ever since the launch, time and again the community has kept asking for a self-hostable version to no avail. And community is requesting that since not all of Supabase is open source. If it were, community themselves would have built it. But Founders have been “milking” the words “Open Source” and ignoring the community altogether. Here is the full story : Few weeks ago, I checked supabase self hosting documentation again ==> they were callous enough to even mention how to move away from Supabase and had no instructions to self host! Completely put off by this unethical means of taking community and words open source for granted, I prompted them about it. And their response has been to remove “How to Self host” section altogether from the website, documentation and Github. And then provided a fully watered down version of docker-compose which “is barely functional or useful” to community as it has no dashboard within it. Whenever self hostable questions comes up, Supabase Founders cover up by providing vague answers like ==> “We are building with existing & proven OSS tools. We stitch them all together seamlessly”. When decrypted, that translates to ==> “We use open source to build our software (hey nothing special here : bazillion companies do that). There will never be a usable self-hostable solution in near future”. F** you Supabase. Every single open source company that I can think of can be self-hosted. World class open source companies go to great lengths to ensure its always self hostable even by compiling source. Supabase founders : You should be so ashamed of yourself for setting such low standards on what could be termed as open source.

harporoeder 6y ago
I am a little confused by your description. I do not use Supabase but the source appears to be available on github and is actively updated. Are you claiming that because they do not provide clear documentation on how to self host they are not open source? Perhaps a good Samaritan could read through the repository and write some basic documentation which is enabled by virtue of being open source.
- yclurker 6y ago

patatino 6y ago

Can I ditch uploadcare and use supabase storage when "CDN integration" and "Auto transformation & optimisation" are ready? Or does is not compare?

inian 6y ago
Yes, it is comparable. We will support all the basic transformations like resize, crop, rotate, etc. Advanced transformations like object detection is not in the immediate roadmap, unless there is demand for it. In terms of asset optimization, we are planning to go all out though. What features of Uploadcare are you using?
- patatino 6y ago
  I do not need advanced transformations, just basic image uploading and displaying on my websites. The best feature for me is the react widget which I can quickly drop into my project and just be done with uploading. Maybe that would be a great feature in the supabase/ui project in the future.

robertlacok 6y ago

Hey, cool product! I'm curious - I saw you use Auth0 for your hosted solution, even though your own platform offers auth. Do you plan to use Supabase for Supabase?

kiwicopple 6y ago
Yes, definitely. When we launched Supabase we didn't have Auth which is why we use Auth0. Migrating has been in the backlog for a few months now. Now that we have shipped Storage, we should have a bit more time!

macklemoreshair 6y ago

Not impressed so far. We use firebase and would never consider moving over to this in its current state. Why would I pay for some hack on top of Postgres?