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
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.
If you really care about open source software, as you seem to, you should know that attitudes and statements like this are just about the worst thing for it. Self-hosting isn’t the only benefit or purpose of OSS. It’s fair to point out that it isn’t easy to self-host, but consider doing it without being poisonous.
> Self-hosting isn’t the only benefit or purpose of OSS
I would say that making self-hosting difficult is completely against the spirit of OSS.
I certainly wouldn't expect an OSS technology to lock me in. At that point it just becomes a privative technology that builds upon open source and exposes its interfaces.
And I say this as someone who very regularly makes strong cases for the hosted solution in a make vs. buy scenarios, and would therefore probably argue to pay for Supabase hosting instead of complicating everyone's lives in my organization.
That's a fair criticism. We've looked closely at everyone's comments and it's obvious that we need to make self-hosting Supabase much easier. This has always been the intention and has always been possible: everything except our dashboard has OSI-compatible licenses, so anyone can run the same back end that we do.
But "technically possible" isn't good enough. It needs to be straightforward, and we're going to invest some effort into making it so. The only thing I'll say in our defence is that this didn't happen for business reasons, i.e. there's no secret plan to hobble the self-hosted version. Quite the opposite, we want the open-source tech to be super easy for everyone to run. We only want people to pay us because our paid product is valuable, not because the free tech is somehow hard to use. We only introduced billing yesterday, and we aren't charging anyone yet. But from the feedback, I understand why this wasn't obvious. It needs to be much clearer how to put the pieces together and we're going to prioritise this now.
I have started updating [0] our docs in this PR [1]. We will merge this tomorrow morning as part of our CLI release [2]. The Docker setup in this PR is 100% compatible with every project on Supabase, and we also link to several of the one-click tools which we have deployed into the AWS and Digital Ocean marketplaces. All this still needs improvement, this is just a first step. If anyone still has trouble setting up a self-hosted version of Supabase, please contact me (my email is in my profile) and I'll personally do whatever it takes to get you up and running. Then I'll update the docs some more so those difficulties won't happen again. Hopefully with a few more iterations this will be as smooth as it should be. The tech is there and 100% ready to go.
I'm just an observer, but this response seems pretty top tier. I've seen your posts here for a while... I think the issue stems from a lack of clarity about what is free/open source, and what is proprietary. Ive read all your releases and am just now seeing that the dashboard is proprietary. Just to be clear, I'm not criticising the business model, but am just providing my 2 cents on a potential cause for "backlash" - namely, clarity in pricing.
Nakama is a similar open source + commercial hosting model. I think the model is strong and we will see it proliferate in the future. You simply can't beat the development power that a good open source ecosystem can bring.
this is what soured me on piwik (now matomo) as a self-hosted web analytics solution. they allow you to self-host, but make it difficult to automate updates, to steer you to their hosting service instead.
it’s been a couple years now, so i don’t remember the details, but i tried to workaround the limitations and came away with the conclusion that automating upgrades was intentionally crippled rather than simply neglected. there was no documentation on it, and it was explicitly touted as a feature of the hosted product.
the problem is one of messaging and positioning in line with the parent comment’s criticisms. instead of calling the non-hosted version a limited demo, the implied claim is that the non-hosted version is ‘production-ready’. but ‘upgrades’ were fresh reinstalls, complete with database integrity issues at stake. it was clearly a gotcha situation to steer you quickly to the hosted version (rather than being upfront about this significant limitation).
Yes this is misplaced anger. I remember long time ago I tried compiling PhantomJs.exe (it's now defunct but it was a alternative to puppeteer). It was insanely hard to compile the latest release for Windows. I had to actually hire and pay someone to do it for me.
Yet I could not be more thankful to the creator of PhantomJs for the work he put into making it. The source code was all there but I wasn't able to do it. But the person I hired did eventually. I am only thankful to the people who make anything open-source and are kind enough to share the code with the world to see and learn.
Supabase started Open Source , their GitHub repo had tutorials on how to host the platform yourself with a bit of documentation.
Basically from what I understood they've been growing SO FAST ( they raise 10+$M IIRC ) they had to make a choice between "Growth" or "Integrity".
Obviously it's a YC company , the market they're going after is massive , they chose growth over integrity and doing things "that don't scale" but that have "traction".
I agree with the author , the founders should come clear about the marketing and the status of Self Hosting and Open Source...
Supabase is no where near Open Source as it promised when it was published on HN few months ago... It's getting closer to a "MuleSoft/Serverless Inc" type of thing that lets you connect your own providers...
Don't get me wrong , I'm saying this because I'm an Enterprise Architect in one of the largest Bank in Europe , I desperately need an Open Source Firebase Clone to move 300+ Developers and Business Analyst into a Cloud First / Product Focus model away from legacy Cobol Enterprise App, Supabase seemed the ideal candidate.
I do think we could have better/cleared docs, which we can fix up tomorrow.
Re investment: we raised 6M, and we are under no pressure to trade our integrity for growth. We have open-source-friendly and patient investors (Mozilla, Coatue, YC), and a nice group of developers: https://supabase.io/blog/2021/03/25/angels-of-supabase
Is there a difference between Firebase's "open source" and Suprabase's "open source"? Is Suprabase more open than Firebase in some manner, or does "an open source Firebase alternative" just mean "a Firebase competitor that also open sources its client side tools?" Is some part of the Firebase code closed source or less "Open" where the Suprabase equivalent is not? I haven't used Firebase much, so maybe I'm missing a big distinction.
This is the set up we use for every project on our hosted platform. These backend tools are either built by Supabase, supported by Supabase (we employ maintainers), or licensed with OSI-compliant licenses.
Our client libraries are all open source, Apache 2.0 licensed.
Supabase is open source in every definition of the word. I think the problem is our self-hosting docs, so we'll spend the day improving this.
Ah, gotcha. So Supabase has backend that is also open source which could theoretically be used for self hosting? Yes, that is a difference. It wasn't clear to me from the docs. Thanks!
Firebase is completely closed source and make it extremely hard to migrate any moderate size project.
Supabase builds on open source parts that everyone is already familiar with. Postgres for data store instead of firestore (which is a proprietary nosql Google cloud database with many quirks to keep you in). GoTrue for Auth which is an open source project by netlify. Real-time to provide Postgres changes over sockets open sourced by them. There are many parts which make up "supabase".
Supabase hosting provide a unified experience through their dashboard and manage all these parts for you. That isn't open source.
The actual UI kit for that is open source, though.
Dashboard doesn't stop you from migrating your backend infrastructure somewhere else. It does result in degraded developer experience which can be the biggest distinction.
I think what more they want is the dashboard, which isn't open-source or self-hostable. Sort of fair ask, but also pretty fair for Supabase not to provide that IMO.
They also want better self-hosting docs, though IMO it's fair for that to be primarily driven by community forums.
Supabase started because we open sourced a "change data capture" server on top of Postgres[0]. We then chatted developers to see if they wanted to use it. In our conversations, many of the developers were using Firebase because it was "just easier" to get started.
We really like Postgres, so we decided to make it as easy to get started as Firebase. We aren't modifying Postgres, or trying to turn it into something proprietary. We want migration to/from to a simple pgdump wherever possible. We provide some tooling around it to make it a better experience (for example, auto-generated APIs using PostgREST).
On a side note: YC encourages naughtiness. This may, on rare occasions, leak into practices that some consider "unethical". And it must be noted, the term "unethical" can be interpreted in so many different ways.
Reddit used an "army of fake accounts" with no open objection from YC. Is this unethical? Depends who you ask. I personally think it is slightly unethical. See https://news.ycombinator.com/item?id=4139876
I can see their reasoining. Everyone does it. If they didn't do these practices, it would be a competitive disadvantage
Finally, I do not agree with the rude tone of parent comment. There's a way of addressing people. I want to thank the Supabase team for their fantastic work + insights. I realize their need to stay competitive. Perhaps they should instead say they are "Open Core", which will remove most criticism.
YC does not go along with unethical practices. I'm not involved with that side of the business but they're serious about it and have disowned companies (by returning their investment and excluding them from the YC community) for being unethical.
I'm confused about what the issue in this case is. It sounds like some people are complaining that the product isn't open source because it's not self-hostable, while the founders are saying that it both is open-source and self-hostable? This sounds like a misunderstanding to me.
Even if it's not a misunderstanding, but rather a difference of opinion about how words should be used, that's not likely really an ethical issue. Rather, the definition of 'open source' is a classic flamewar topic that people regularly post zealous denunications about (including fiery charges of unethicalness and the usual "you should be ashamed" etc.). Of course this is not helpful—it just leads to flamewars, which are off topic on HN, and makes clear communication harder.
It does seem like "open core" is emerging as a term for startups that have open-sourceiness in some sense but not in every sense. That's one way to short-circuit flamewars and we've helped at least a couple YC startups launch themselves that way. But I don't know if it would be a solution in the present case because I don't understand what the issue really is.
(I'm not saying any of this because I think you personally need to hear it! I'm just posting it here out of caution, because if I jump into the argument directly, people will accuse me of putting a moderator thumb on the scale. We have to moderate HN less, not more, when a YC startup is involved: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...)
Simply put it hits a nerve because the community is inundated by companies saying one thing and doing another when if they had just been straight forward in the first place it would have been no big deal. These one-off dramatic events (like Google shutting down a minor service) and comments (like "it's Founders are highly unethical") are often small-fries or based on weak and ineffective arguments. But they are straws on the camels back and the camel is overburdened like a Valheim character carrying too many items.
I believe accusations of YC being unethical is a secondary affect of this zeitgeist as well. Whether it's the musings of PG or a portfolio company that goes off the reservations on extremely rare occasion, people connect the dots back through YC and see some culpability - even if YC's influence over poor decisions of founders is non-existent or contextually irrelevant. YC is in the supply chain and comments like "Startups often have to do slightly devious things" do not help.
Granted its unfair for Supabase or YC to be smeared by the general discontent of parts of the community. However it's also true that they are in positions of leadership and privilege (and candidly also often multi-millionaires) and should expect some flak as a result.
I think all Supabase's CEO or PR person should do now is post a short timeline outlining Supabase's public statements of being a self-hostable product (or lack thereof), clearly define the company's position at the time of any statement(s), clearly define what their position is going forward, and make a brief show of humility and apologize for not being as clear as they could be to their users. Granted this takes time, and its a singular internet comment evoking the response - but it would negate the negative sentiment and provide a basis for defending against similar statements in the future.
Anyways, I won't miss the opportunity to thank you for the support and moderation you do for the community, its been a valuable resource for me and I hope my personal perspective contributes to the general conversation.
> We use open source to build our software (hey nothing special here : bazillion companies do that)
That's not true. Supabase improves and builds the open source ecosystem it uses.
In the case of PostgREST, we've added performance improvements that could very well be in a private fork(which other companies have done), but Supabase, in the good spirit of open source, decided to make these changes upstream.
The same goes for realtime, the team has been improving its performance to an enterprise-grade and making all these changes open source.
Even the storage API[1] presented here is OSS.
I believe all of these efforts are a net win for the open source community at large. Zealotry doesn't help anyone.
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.
They are not providing the missing source codes to put together a self hostable solution. Essentially they are not open source. Otherwise writing documentation is trivial by one of the community members.
To the founders of supabase: don’t let people like this deter you. Their misplaced anger and self-righteousness says more about them than it says about you. If your software is good, we will use it. If it’s not, we won’t. There’s no need for poisonous behavior either way.
I think most F/OSS YC companies are adopting the GitLab model. Which is why may be they have put their UI code behind closed doors, because the "buyer-based open core" business model is, in part, based on it: https://www.heavybit.com/library/video/commercial-open-sourc...
The comment I'm replying to is a pretty hot take (maybe too hot), but IMO the real test will be when someone else tries to run a Supabase-aaS platform.
The unspoken implication of "self host" is "for yourself and no one else", but there's a bit of a difference between Supabase and the project it's using underneath -- I can absolutely run GoTrue or Postgrest aaS, but I assume that Supabase will change their minds on their license stance if someone does the same and undercuts their margins.
Why not just pick BSSL and be done with it like Sentry does -- no one gets mad at Sentry. Maybe it's the allure of getting people excited about your project and contributing to it?
Another weird thing is that projects picking AGPL (which is their right in every way) usually signals a similar intent, but AFAIK AGPL doesn't actually stop you from running an aaS, as long as you don't modify the source.
One more weird thing -- why doesn't anyone ever make a Firebase clone that is just... API-compatible with Firebase libraries? Being able to use the Firebase SDK itself but talk to a different set of cheaper servers is what everyone in this niche really wants right?
Make the license BSSL (or AGPL, or whatever you want), and if you don’t already have it get out there and make your “fuck you” money, because that idea seems like almost a sure thing!
Having to so none of the marketing and just showing up on “firebase pricing” or “firebase cheaper” searches or whatever feels like a slam dunk, and since you’ve picked postgres you’ll probably have a nice well trodden path to reliability and perf
Can also attest to this. One of the companies I advise looked into them recently before realizing the “open source” is marketing folly. Quite disappointed in YC not doing their due diligence with them.
I'd be happy to chat to the this company to clear up any misconceptions. Is it because we have a hosted platform that they think we're not open source?
Our source code is available and permissively licensed in our github org: https://github.com/supabase, and we are very particular about picking MIT/Apache2/Postgres licensed tools for the stack.
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.
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).
> 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 ...
This is the first approach that I could think of, so it's good that you also mention that -- I was slightly worried that I might be missing something. Definitely looking for the mystery announcement :)
> 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).
Regarding simplicity, it's something that occurred to me as well and one of the selling points. The happy path for Auth0 is simple enough, but when one has slightly different use-case, it's a tad too complicated for my taste. Fortunately, I don't need enterprise features so I'll experiment with integrating my project with Supabase.
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.
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.
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)
"Powerful" maybe for the pub/sub capabilities that allow you to trigger actions on write and whatnot?
I don't know if Supabase has this, but at any rate I don't find anything else about Firestore "powerful", it's just a NoSQL database with all the pitfalls of NoSQL, a more limited API than MongoDB, a terrible data explorer UI, and very limited local capabilities...
I think this is a bit disingenuous to post. Your own website[1] says:
> Supabase is an amalgamation of 5 open source tools (and growing). We don't have a simple way to install everything on a single server, but we will work on this as soon as we have a stable set of features.
Now, it's fair to say "we don't have a simple way" is different from "we don't have a way at all," but you clearly discourage users from trying to self-host right now for any reason beyond developing Supabase itself (which appears to be the use of the Docker Compose setup you have linked).
Personally: I'd love for Supabase to have a clear guide for self-hosting, including system requirements for single-box hosting, advice (even without code or tooling!) for scaling your setup, etc. Until then, it's just another hosted service with vendor lock-in, no different from Firebase to me.
That's fair, to be honest those docs were written a long time ago and haven't been updated. We're releasing our CLI tomorrow, which is part of the "self hosting" story, so I'll update these docs with some detailed instructions.
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.
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 :)
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
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.
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.
"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."
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.
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!
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?
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
[2] PostgREST: http://postgrest.org/
[3] Realtime: https://github.com/supabase/realtime
[4] GoTrue: https://github.com/supabase/supabase/tree/master/docker
[5] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
[6] Storage API: https://github.com/supabase/storage-api