[HN Gopher] We are moving to General Availability
___________________________________________________________________
We are moving to General Availability
Author : jimmcslim
Score : 209 points
Date : 2024-04-15 11:39 UTC (11 hours ago)
(HTM) web link (supabase.com)
(TXT) w3m dump (supabase.com)
| kiwicopple wrote:
| hey hn, supabase ceo here
|
| we just announced GA, after ~4 years of beta. for those who don't
| know: supabase is a postgres hosting company. we also host other
| open source "backend" tools that make it easy to get started with
| postgres (tools like PostgREST for auto-generate APIs [0])
|
| we owe a lot to the HN community. you launched us 4 years ago
| [1], when we were just a few developers. since then HN has been a
| staple in our journey, one of the best sources of product
| feedback [2]
|
| the GA badge is mostly to signify organizational readiness. we're
| at a stage where we can take any profile of customer. we have a
| support team that works 24/7, and a success team that will help
| customers improve their postgres usage. we released our Index
| Advisor [3] yesterday, and we'll be releasing a few more products
| this week that helps customer with performance and security.
|
| on a personal note: i read HN most days, and love going through
| the ShowHN's to see what devs are building. thanks for being an
| awesome community and my favorite place to lurk on the internet.
| i'll stick around to answer any questions
|
| [0] PostgREST: https://postgrest.org
|
| [1] Launch: https://news.ycombinator.com/item?id=23319901
|
| [2] HN journey:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
|
| [3] Index Advisor: https://news.ycombinator.com/item?id=40028111
| psnehanshu wrote:
| When did the positioning of Supabase changed from a "Firebase
| alternative" to a "Postgres hosting"?
| kiwicopple wrote:
| we're constantly evolving it.
|
| at the start, the "firebase alternative" positioning made it
| unclear to developers who thought we offered a NoSQL
| database. We always wanted to be "Postgres plus useful tools"
| so we started evolving the positioning over the past year
|
| you'll still see "firebase alternative" on our site: I think
| the comparison is apt and the aspiration remains the same
| clarkbw wrote:
| Congrats to the Supabase team! You've all done some impressive
| work to be proud of.
| kiwicopple wrote:
| thanks for the kind words
| Jabbles wrote:
| Why do you not use capital letters in the typical way?
| Takennickname wrote:
| It is a little bit painful to read. Capital letters exist for
| a reason (to make reading easier)
| spencerchubb wrote:
| capital letters are atypical in many internet circles,
| particularly younger. so maybe it's a habit from frequenting
| those circles or a deliberate branding choice
| kelsey98765431 wrote:
| This is not a negative statement against Supabase, but heed my
| warning:
|
| Do not build out your MVP on supabase. If you need to scale and
| want a MSP do it after the MVP. Detangling the lock in is not
| fun.
|
| Everything offered by supabase is easily found elsewhere without
| the MSP lock in.
| xytofs wrote:
| What were the troubles you faced?
| trolan wrote:
| I've used it for a couple uni/personal projects to get some
| experience, and firebase for the same. I'm concerned about
| getting locked in, what other providers do you recommend who
| can let me migrate more easily?
| oliverrice wrote:
| > I'm concerned about getting locked in
|
| Supabase is one of the most portable platforms out there.
|
| The whole stack is self-hostable and open source. All of the
| data are contained in Postgres. You're one pg_dump away from
| being able to switch to a different Postgres host. Or if
| you're switching to something else entirely, you can export
| the data to CSVs and take it anywhere. But we're confident
| you won't want to :)
|
| disclaimer - Supabase employee
| colordrops wrote:
| > Supabase is one of the most portable platforms out there
|
| Not in my experience. The documentation and infra is just
| not there to make it easy to use an external postgres db.
| kiwicopple wrote:
| we know of many, many companies using Supabase self-
| hosted or with an external database.
|
| if you have any problems, feel free to reach out to me
| directly. We want this to be simple (and you can see that
| there are non-supabase commentors in this thread who are
| self-hosting, so it's not just lip service)
| TOMDM wrote:
| I self host a couple supabase instances.
|
| That said it feels like every other week there's an
| update that breaks the self hosted compose, looking
| through the GitHub issue tracker shows a few issues where
| the suggestion is "oh yeah the latest X image doesn't
| work, regress the version to get it running"
|
| I really like supabase, but stability on the self hosted
| images is my biggest gripe with it currently.
| BoorishBears wrote:
| That does not track with anything I've ever seen out of
| using Supabase
|
| If you target Postgres, just about any Postgres instance
| works the moment you enter a connection URL.
|
| You can hop from one managed Postgres offering to another
| in 10 minutes and lose no functionality. Everything from
| auth to programming (and even RLS implemented in the query
| space) will work instantly: no additional software needed.
|
| Are you claiming that's the case with Supabase and its JWT
| auth/RLS entanglement?
| kiwicopple wrote:
| You can use supabase simply as a Postgres provider. Supabase
| is just postgres, and you can choose to use any tool we
| provide (or not)
| trolan wrote:
| I've so far found the most value in authentication, so
| thank you for a great self hostable product
| stemc43 wrote:
| supabase, directus and similar are just wrappers on top op
| postgres. I just spin up local postgres instance for personal
| project and see no reason to get vendor locked-in myself.
| tootie wrote:
| If it's postgres with easily available plugins, then where is
| the lock in?
| atonse wrote:
| We're using Supabase for a client project and even three
| sprints in, we're severely hobbled by having to play with a
| couple of architectural choices forced on us with Supabase and
| Supabase Auth. Any of the time savings benefits have been wiped
| out already just fighting the choices and also the subtle
| differences between the local dev environment, implementing RLS
| without good tooling.
|
| On an architectural level, it is also terrifying to have your
| database exposed to the public internet just hidden behind
| authentication and RLS policies (which are much harder to
| reason about for most developers, and for which there is very
| immature tooling, a recipe for disaster).
|
| Plus the local dev experience leaves a lot to be desired. We
| spent days trying to get file uploads working only to find that
| the issue was with local Supabase, and we had to create a
| remote Supabase database just to upload files successfully. But
| then we can't "reset" the database to run migrations.
|
| The product is definitely much less smooth to develop on and
| I've had to provide dozens of hours of free client consulting
| work to untangle my recommendation of Supabase (didn't feel
| right to charge them to fix a product choice that I recommended
| to them).
|
| Right now I'm in a strong "never again" view on this set of
| technologies. At least not for a long time until the tooling
| improves.
|
| But it seems like there are some happy customers. So would love
| to hear a counterpoint of how they overcame all the issues
| we've faced:
|
| - how are your security teams ok with exposing your PG server
| to the internet, relying mainly on RLS? And RLS isn't turned on
| by default, so full tables are exposed to the public internet
| by default, behind a rather nice REST API.
|
| - Reliance on RLS for a public service seems risky because RLS
| quickly gets harder to maintain as you have to get more complex
| policies in place without much tooling to help you.
|
| - how about the fact that some of your most important code, the
| RLS policies code, is hard to unit test with today's tooling?
| And they recommend pgTAP, which, who knows how big this
| community is?
|
| That combination seems highly risky to me.
|
| Our best bet right now has been to just install prisma and
| implement more traditional filtering on top of RLS, and just
| not rely at all on client side connections to postgres. So in a
| nutshell, moving away from Supabase specific architecture to
| more traditional architecture. The real "It's just postgres"
| xytofs wrote:
| > how are your security teams ok with exposing your PG server
| to the internet, relying mainly on RLS? And RLS isn't turned
| on by default, so full tables are exposed to the public
| internet by default, behind a rather nice REST API.
|
| Tooling is improving constantly and security really is at the
| top of mind for us. We've got some cool announcements this
| week that will keep reminding you if you're doing something
| sketchy!
| atonse wrote:
| Good to hear, thanks.
|
| I really am trying to provide constructive criticism (even
| if my tone is not great because the pain I'm continuing to
| feel with the platform is still fresh).
|
| I do think you guys are in a great position to actually
| improve all that tooling around RLS. Tools that can analyze
| your policies, that can visually map the recursive nature
| of policies that run, etc.
| omnibrain wrote:
| An access-simulator where you can check if a user (or anon)
| has some type of access would be helpful.
| kiwicopple wrote:
| we actually have this:
|
| https://supabase.com/blog/studio-introducing-
| assistant#user-...
|
| and you can expect to see another related launch this
| week with some more in-depth tooling:
|
| https://github.com/supabase/splinter
| listenallyall wrote:
| Kinda sounds like "client side connections to postgres" was
| the poor decision at root of your security concerns, not the
| choice of provider
| srcreigh wrote:
| Client side connections and RLS are the Supabase blessed
| path in the getting started docs
| listenallyall wrote:
| Don't go to production with what's in "getting started".
| atonse wrote:
| But that is the path that Supabase strongly recommends if
| you use their tech stack.
|
| I fully agree that some of the issues (like poor RLS
| tooling) doesn't necessarily fall on Supabase's shoulders.
| But this is the path that Supabase strongly recommends.
|
| So you kind of can't have it both ways and say "Supabase is
| just Postgres" but then say "this is not our problem, it's
| postgres", right?
|
| I actually think Supabase is in a GREAT position to
| actually build some of this missing tooling. They're
| probably now the single largest beneficiary of more people
| using RLS.
|
| So I do think they will tackle this problem, it is a smart
| team. I just think that because of these issues, as a
| cohesive platform, it definitely doesn't feel fully baked
| (or "generally available" status) yet.
| Difwif wrote:
| This isn't fair feedback. You have to be more specific about
| the "lock in". Supabase itself is just managed Postgres and can
| be self-hosted. The entire point is that everything they offer
| is open source and easily found elsewhere.
|
| I can imagine they fall short in some aspects from that ideal
| and I would love to know your experience but even with your
| first sentence this is just a pretty damning write off.
|
| Disclaimer: I'm NOT a Supabase employee, just a happy user.
| BoorishBears wrote:
| People keep writing this, doesn't Supabase rely on spinning
| up additional services to leave, meaning you can't leave to
| another managed offering?
|
| Off the top of my mind, PostgREST and go-true?
| https://github.com/supabase/auth
|
| -
|
| If you use Postgres you're "locked" into Postgres: a
| technology with a laundry list of providers.
|
| If you leave Supabase, you'll lose the fully managed aspect
| of 99% of the Postgres providers out there, which confirms
| the pain the parent comment is describing.
| xytofs wrote:
| You can just take the Auth server, run it yourself with an
| AWS RDS instance for example, keep up with updates and be
| good to go.
|
| Yes you get a good UI with Supabase, and even much of that
| can be hosted yourself.
| kiwicopple wrote:
| this is no different than running, say, Rails on a managed
| service. You can take the service and you run it somewhere
| else: each individual service is wrapped into a docker
| image which should make it easy.
|
| You can use as many or as few of the services as you want -
| its designed it that way:
|
| https://supabase.com/docs/guides/getting-
| started/architectur...
| BoorishBears wrote:
| This just sidesteps what I said?
|
| Supabase is most attractive to those without the skills
| to run an unmanaged service
|
| A bespoke solution, even if it's open, doesn't mean it's
| as portable as a very standard solution.
|
| If you want portability, the parent comment was right:
| don't embed Supabase deeply into your application.
| kiwicopple wrote:
| let me have another run at it:
|
| > If you use Postgres you're "locked" into Postgres: a
| technology with a laundry list of providers.
|
| Supabase is just a Postgres platform, and you can use it
| like that so that you can migrate away to any one of
| those laundry list. We _also_ provide some tools which
| are nicely integrated but importantly: they are optional
|
| > doesn't Supabase rely on spinning up additional
| services to leave,
|
| No, not if you don't use those other services. If you
| _do_ decide to use another service, then yes, you need to
| spin it up to leave (or migrate to something else). Hence
| my comment: this is no different than running, say, Rails
| on a managed service.
| waldrews wrote:
| Sorry, confused by the wording: what does 'spinning up'
| mean here?
| jddj wrote:
| Configure and begin running
| switchbak wrote:
| You're suggesting a hosted Postgres offering isn't "as
| portable" as a very standard solution?
|
| This isn't DynamoDB here, this is about as standard as it
| gets. I'm failing to find the supposed lock-in being
| talked about here.
| BoorishBears wrote:
| Is having your frontend hook directly into to your
| database without a backend a standard? I almost
| exclusively saw it in locked in BaaS platforms over the
| years (like Firebase)
|
| I've barely even seen PostgREST offered managed: is even
| one managed Postgres provider with the right combination
| of PostgREST and go-true to let you move over today?
|
| Edit: I also don't get why this is such a point of
| contention...
|
| Since when is BaaS _not_ just a trade off between initial
| velocity and later stage lock-in? The former is not
| worthless, but like most tools you should understand the
| tradeoffs involved
| szundi wrote:
| Better step away from your keyboard then, until you start
| to use something and getting locked in.
|
| Point is that if you need to be free, the barrier is
| lowER.
| kwerk wrote:
| Congrats! Happy supabase user here
| samoit wrote:
| I also know appwrite. It looks quite similar to me, has it the
| same target audience?. Is there any comparision chat? Thanks.
| pastor_bob wrote:
| Curious to see how many of those million databases are from free
| users.
|
| Feels like we're living in the golden age of free platform
| offerings.
|
| Wonder when the shoe will drop.
| burggraf wrote:
| > Curious to see how many of those million databases are from
| free users.
|
| A LOT! Probably most.
|
| But Supabase is committed to the free tier and it's not going
| anywhere. It's crucial to helping demonstrate all the features
| and the DX to developers.
| mattjenner wrote:
| I am happily using the free tier to help launch my startup. It
| is invaluable to me. I am a big fan of it, and have no regrets
| with this decision (only 9 months in). I admire what I am
| allowed to have for the low price of 'free now, pay when you
| need to'.
| noob-4-life wrote:
| Awesome, the Index Advisor sped my slowest query 4x! Is there a
| way to run that across all queries in pg_stat_statements at once
| or do I need to click on each one?
| oliverrice wrote:
| In Studio you'd need to click on a query to get the
| recommendations but the most important queries to optimize are
| on several metrics like "Most time consuming", "Most frequent",
| "Slowest execution" are sorted worst-to-best in tab views.
|
| But if you do want to scan all of your queries at once for
| possible indexes you can do it in SQL with
|
| ```sql
|
| create extension index_advisor cascade schema extensions;
|
| select ia. _, pss.query
|
| from pg_stat_statements pss, lateral( select _ from
| extensions.index_advisor(pss.query)) ia
|
| order by (total_cost_after::numeric -
| total_cost_before::numeric)
|
| limit 100;
|
| ```
| lbrito wrote:
| Any news on the integration with Fly.io going GA?
| kiwicopple wrote:
| it's progressing! we'll have some news on friday
| benzible wrote:
| From a recent post by a fly.io employee in their forums [1], in
| response to being asked "do you expect it to be ready for
| production use this year?"...
|
| >Coming very soon, we'll be moving to public alpha (which in
| our world, comes after private beta :smiley:).
|
| [1] https://community.fly.io/t/supabase-managed-postgres-in-
| priv...
| jmeyer2k wrote:
| Congrats on the launch!
|
| Here's our experience with Supabase at https://automark.io
| (Next.js + Supabase).
|
| - First of all, Supabase let us launch fast which was amazing.
| Super powerful Postgres features without the pain of self-hosting
| (or so we thought).
|
| - We started out using their hosted product for both our DB,
| storage, auth, and functions.
|
| - Functions have a critical bug that prevent us from using in
| development so we decided to move to our own API servers:
| https://github.com/supabase/edge-runtime/issues/212
|
| - Now, the connection between our API servers and the database
| was slow (a few hundred ms per query), so we moved to self-
| hosting Postgres which was pretty painful. We tried to use
| https://github.com/supabase/postgres, but the documentation was
| very lacking and we had to make a bunch of modifications to get
| it to work. After we got it working, it was pretty smooth though
| - pretty easy to implement backups, etc.
|
| - Our latest issue has been around auth where the cookie name
| options change. We've spent hours debugging random cookie issues
| deep in the auth framework (they finally released `@supabase/ssr`
| which is pretty decent, but we're still thinking about moving to
| handling auth on our side so we know and can debug the logic).
|
| One thing to mention: although our requirements didn't quite fit
| Supabase and we ran into these issues, we weren't locked into
| their hosting. We were able to completely move off of it over the
| course of a few weeks, but continue using the self-hosted
| version. This is a huge benefit over something like Firebase or
| Amplify. We're pretty satisfied with Supabase as an open source
| project, but not as satisfied with Supabase hosting.
| kiwicopple wrote:
| > _We 're pretty satisfied with Supabase as an open source
| project_
|
| As an open source company, we'll take that as a mark of
| success.
|
| Thanks for the details, I'll jump into that GH issue with the
| Edge Functions team after this week
| moomoo11 wrote:
| Hi.
|
| Do you guys spin up individual Postgres instances for people
| or use some multi tenant approach?
| kiwicopple wrote:
| Yes, it's a full Postgres database.
| k_vi wrote:
| Tried Supabase but currently only use their Auth.
|
| The server to database latency was very high(few hundred ms)
| whereas Planetscale DB in the same region gives sub 10ms.
|
| Still great option for most projects that can do with these
| issues.
| williamdclt wrote:
| I struggle to imagine projects that can do with a db latency
| of several hundred ms? Something fully async maybe, any human
| interaction would be incredibly slow
| wirelesspotat wrote:
| How far was the server from the Supabase instance?
|
| I have a toy project with a server on Fly.io and the DB on
| Supabase within the same city
|
| When sending API requests to the server, my end user latency
| was around 25ms-100ms (depending on the endpoint and how many
| DB calls it was doing)
|
| Now with Supabase on Fly, that API latency is down to
| 17ms-70ms. But Supabase on Fly is still in alpha so it's not
| relevant for production yet
| CharlesW wrote:
| Congrats Supabase folks! I wish you every success.
|
| I paid $20/mo for a while because of the free tier storage cutoff
| (500 MB), but have since stopped. I wish you had a $5/mo tier for
| "small projects" folks who need a database larger than that.
|
| For example, Cloudflare's Workers Paid is $5 for D1 databases up
| to 10GB, with 5GB included and 75C/GB after. I know this is
| comparing apples and oranges to some degree and that your
| business model may be incompatible with this use case, which is
| absolutely fair.
| trevoragilbert wrote:
| Happy Supabase user here, albeit on a tiny app I work on in my
| spare time. So no comment for larger or more complex orgs.
|
| That being said, the Swift documentation could use some love.
| It's not terrible but it's also not great. There have been a
| number of times when I wanted to do something, ended up reading
| about it on the Supabase JS documentation, and then thought "well
| I assume it's roughly the same in the Swift library." It worked,
| but a pain to have to guess a lot.
| kiwicopple wrote:
| we just took over official support for swift:
| https://supabase.com/blog/supabase-swift
|
| I'll let Guilherme know. feel free to reach out directly with
| any specific feedback
| eddieroger wrote:
| I would add that it's gotten better since it was folded in
| for official support, but it could still use some love. So
| cheers for improvement, and stay at it. It's encouraging to
| see a community add like this folded in to the main.
| trevoragilbert wrote:
| Ha, the timing makes it look like you did this in response to
| my comment. :D Very excited about this!
| SadWebDeveloper wrote:
| I'm a full stack developer and still don't know what supabase
| does other than being a firebase replacement...
|
| Like seriously are they seriously trying to sell us how difficult
| is to setup a simple nginx server? Not sarcastic just an old
| developer that hasn't get this new fad of going "serverless".
| giraffe_lady wrote:
| It's not serverless it's a postgrest API over a DB. Which is
| plenty of backend for many of my purposes. Postgres's RBAC is
| sophisticated enough to use as your entire auth layer if you
| know what you're doing with it. After that it's a free rest
| API.
|
| I'm not like a supabase diehard or whatever but I have used it
| to great success in a handful of projects, especially early or
| proof-of-concept stage ones. For me it's not a replacement for
| nginx it's a replacement for rails.
| cljacoby wrote:
| They seem to heavily invest in their social media presence with
| things like the YouTube channel, but then also use social media
| indicators (likes/follows/subs/etc) as a measure of success.
| Seems a little circular.
|
| The plot of Github Stars over Time: Supabase vs. MongoDB seems
| particularly silly (imo).
|
| Not a hater by the way, I think their YouTube channel is actually
| pretty good, and I think it will become increasingly common for
| startups/businesses to have something like this for product/brand
| awareness, getting users up and running, etc.
|
| I think if the goal of the post was focusing on platform
| maturation and growth, it might have been better to focus
| exclusively on the plots of database/users over time, and simply
| link out to the various social channels.
|
| Overall though still cool to see, and congratulations to the
| Supabase team!
| hackerman14 wrote:
| Interesting how they posted a self-host guide just a few hours
| before announcing this.
| https://www.youtube.com/watch?v=FqiQKRKsfZE Perhaps expecting
| criticism and preemptively creating a response that shuts people
| down?
|
| Ultimately I just see the same pattern in Supabase as in many of
| these "easy scaling" solutions: lock in. I think the future is
| something like those platforms are offering but we're definitely
| not there yet. Also it's not like I'm an old person refusing to
| accept new tech. I'm young and looking to create things but I
| recognize that these services are (currently) doing the complete
| opposite of giving me freedom.
| kiwicopple wrote:
| the video has been available on our self-hosting docs
| (https://supabase.com/docs/guides/self-hosting/docker) for
| months (see comments age). I just noticed that it was
| "unlisted" instead of "public" when I was making this GA page
| so I made it public. There isn't anything sinister here
|
| > "easy scaling" solutions: lock in
|
| This has been hashed through in a few comments on this post:
| Supabase is Postgres. We offer tools on top which you can
| _optionally_ use. Some people love those tools (especially
| Postgres maxis). Some people prefer to just use the database
| with Django/Phoenix/Rails/etc. You choose your own level of
| comfort.
| tasubotadas wrote:
| How it compares against neon.tech?
| imbradn wrote:
| The acquisition of Oriole is very interesting. Getting that to a
| GA product would be a game changer for a lot of workloads.
| tristan957 wrote:
| I'm excited for more OrioleDB patches to land in upstream.
| Sounds exciting.
| davetron5000 wrote:
| I built a toy app using this, with a front-end only app and
| postgrest + RBS. The app was seriously two forms behind a login.
| It was a huge pain.
|
| RBS is "insecure by default" meaning if you don't set it up
| right, all users can access all data. And, because it's SQL, it's
| really easy to write a valid and successful configuration that
| doesn't work. You have to test it. And for views, you have to do
| some real heroics to get them to respect RBS.
|
| PostGREST is very very basic and far less powerful than just
| writing SQL. I found it pretty frustrating to use, knowing that
| SQL would be far simpler.
|
| Yes, I know that I could make a direct SQL connection to the
| database, but at that point, it would've been easier to put a
| Rails app on Heroku and use their offering, which is far more
| mature.
|
| The Supabase dev environment was pretty slick and worked well,
| though I had to docker implode a couple times.
|
| I wish them luck, but I could not figure out what the use case
| was for their product, given that Heroku has an awesome managed
| Postgres and RDS is there if you have more knowledge and want
| more controls. I don't see how you could make a complex app that
| is front-end only with Supabase as your entire back-end.
| TOMDM wrote:
| A few things, RLS is secure by default, it's postgrest that's
| insecure by default.
|
| RLS disables all operations on a table once enabled and is only
| operable once there's a passing policy unless you can bypass
| RLS.
|
| When it comes to access control, you should probably always
| have tests for anything halfway important.
|
| Views are a bit of a footgun when it comes to RLS, they bypass
| it by default. But getting them to play nice is as simple as
| defining "security invoker" in their definition; not what I'd
| call heroics.
| steve-chavez wrote:
| > A few things, RLS is secure by default, it's postgrest
| that's insecure by default.
|
| What makes you think that? PostgREST delegates all the
| authorization to PostgreSQL, which is secure by default. You
| have to explicitly assign privileges to roles for every
| operation.
|
| Relevant previous discussion:
| https://news.ycombinator.com/item?id=38689294
| vbezhenar wrote:
| I'm not supabase client, so I guess my wishes do not matter much,
| but I'm self-hosting it and the experience was not pleasant. They
| just gave me some huge docker-compose with barely any
| documentation about it and that's about it. My approach to self-
| hosting software is carefully learn about every service I'm going
| to run, disabling everything not needed for my use-case. That was
| not possible with supabase without significant time investments.
|
| So my wish would be for supabase to provide some kind of minimal
| bare-bones configuration and careful documentation for their
| monstrous docker-compose configuration with explanations why all
| parameters were set to non-default values. I don't think that I
| need all those services if I don't use any of them except
| database and sometimes admin UI.
|
| Also I think that I even had to edit some configs for api keys or
| something like that. It should not be like that, everything
| should be passed down via envs.
|
| Right now I've set up supabase for our developers but asked them
| to migrate to plain postgres as soon as possible, so I could move
| production workloads to our standard setup.
|
| My ideal setup would be one postgres instance which I can install
| myself from plain docker library image; one golang binary which
| embeds everything supabase offers turned off but with some envs
| to enable and that's about it.
| owenversteeg wrote:
| Supabase is great - I use them now and they and would be my
| choice for a new project today - but I have to say I am not a
| huge fan of how they communicated the whole auth-helpers and ssr
| situation, and I am not the only one with this comment by a long
| shot. This is, I think, a part of wider issues with their
| documentation; it seems like whoever's doing documentation at
| Supabase is intelligent but stretched thin. Particularly for
| Sveltekit, the documentation and examples are incomplete, there
| isn't any guide to migration or how to modify your code, and if
| you Google things or follow any links or examples you quickly end
| up in a web of deprecated repositories where it's unclear what to
| do next or replace them with. One example:
| https://github.com/supabase-community/auth-ui
|
| If you produce a product for developers, you really need to have
| 1) quality, readable documentation with an introduction that
| noobs and pros alike can follow, 2) multiple complete, cloneable
| examples on how to integrate and use your product in several
| different libraries, 3) obvious migration guides and timelines
| whenever you deprecate something. Supabase lacks all three, which
| is extremely frustrating and means there's always a giant caveat
| when I recommend them. They're still the best, it's a very
| powerful and impressive product, and the possibility of self-
| hosting is amazing.
___________________________________________________________________
(page generated 2024-04-15 23:00 UTC)