Anyone used Phoenix + Supabase?

Phoenix Forum Questions / Help
,
21

The way I understand multi-tenancy is that it allows multiple apps to use the same database.

If the authentication system is running inside the database, then you can write a half-dozen different front ends and you won’t have to worry about implementing an auth system each time you do that.

Without a database layer auth system, you can’t have a half-dozen different apps all providing different views and functionality over the same database layer without either:

  1. giving each app the database credentials and hoping they don’t mess up the data and carefully coordinating between them all

or

  1. bundling the half-dozen apps all within a monolith Phoenix app

It seems to me that both of these approaches have a clear downside.

In the first case, passing out your database credentials to various short-term contractors you’ve hired and then making sure each of the half-dozen apps is careful about data and has solid auth logic is just dangerous and requires too much coordination.

In the second case you’re bundling code together that doesn’t really belong together, making a much more complex app, and you also cripple the ability to just use a different tech stack altogether where it may make sense for some oddball niche use-case.

In addition, an auth system that runs within Postgres is more secure because it is more difficult to get around (by virtue of being closer to the metal) and is also more powerful because it allows for row-level security, which allows for much more granulated control.

In short: using a Postgres-layer auth system is more powerful and more secure, but is also more flexible.

The final thing I’ll say is that the BEAM ecosystem really shines at solving a particular kind of problem – it is good for systems that need easy and scalable multi-threading along with a supervision system to make it highly reliable.

The BEAM was not built for writing front ends, and nor was it built to be a way to talk to a database. It was built to reliably keep a million processes running through thick and thin. By using a Postgres-level auth system, you can keep your BEAM code focused on what it does best while also adding flexibility, and leave the stuff it was not meant for to be done by other technologies that were in fact meant for them.

I’m actually curious about what I’m not understanding here – I would love to hear someone make a counter-argument to my perspective.

1 Like
22

After going through Pricing & fees | Supabase I realized that supabase is providing storage at a price that is almost equal to S3. That is one area of concern when you actually use https://fly.io as deployment destination. The pricing of storage in Fly is much higher.
I just thought why not deploy a Phoenix Application on Fly with database and storage being served from Supabase. I felt the advantages is you get an edge database and edge storage at much cheaper price compared to Fly. However, Supabase seems to be fully focused on Frontend frameworks - and - nothing in the documentation suggests this sort of stack is possible.
Now my question is:

  1. How do we handle database? For Development, we use regular Postgres Database and for production we use supabase connection string?
  2. How do we handle storage? Should we be using Phoenix LiveView Upload - and treat it as external upload completely and use supabase-js? I am quite confused on how to handle this. Any pointers will be really helpful.
    Is the idea silly and convoluted? Request experienced members to comment.
23

Fly.io actually recommends using Supabase if you need managed Postgres: This Is Not Managed Postgres · Fly Docs

24

I still can’t figure out why Supabase isn’t the go-to database for anyone developing a production Phoenix/LiveView app – it is just Postgres, except better (because it has auth and a REST API out of the box and nice interfaces, etc).

Shouldn’t Supabase be the recommended default solution for a Phoenix app, similar to how Tailwind has become the default solution for CSS in a Phoenix app?

25

I couldn’t quickly find where supabase is hosted, but generally: US based services are currently a very dark gray area in regards to GDPR. Generally you’d want your DB as close to your app servers as possible, which usually means same datacenter.

More generally I don’t think it makes sense to compare a payed third party service to an open source library.

26

What do you mean by “I don’t think it makes sense to compare a paid third-party service to an open-source library.”?

I get that Supabase is a paid service, but so is Fly.io.

If we assume that we’re trying to build an app that is not just a demo or a toy, but one that is going to have thousands of real users who are paying real money, then going with some sort of paid and managed Postgres solution is the only thing that makes sense, right?

27

There are guides to integrate with fly.io, and fly’s CLI integrates well with phoenix projects, but non of the code phoenix ships is bound to fly.

28

Yes, I understand that Phoenix and Fly.io are not integrated out of the box.

When I suggested earlier that Supabase should be the recommended default database solution for Phoenix apps, I didn’t mean to limit that suggestion to apps that are deployed on Fly.io, and I didn’t mean to suggest that Supabase should somehow become integrated with Phoenix the way Tailwind is getting integrated as the default CSS solution.

What I meant was: shouldn’t the community recommend Supabase as the most sensible database solution for anyone building a Phoenix app unless there is some particular and unusual scenario that would call for a different database solution?

And given that Fly is a popular deployment solution and that Fly.io seems to warn against using their Postgres database solution (because it is not managed) and they specifically recommend Supabase, doesn’t it make sense for Phoenix+Supabase to be the accepted sensible way to run a production Phoenix app?

Also, since Supabase gives you auth, that problem is also solved.

29

Tbh I really like that this community is mostly going the other direction: Being considerate in not putting any solution on a throne, but rather discussing tradeoffs in possible solutions. I personally would consider CrunchyBridge the much more sensible managed database hosting, as it’s to my knowledge plain postgres with common open source extensions. Limit the amount of vendor specific stuff as much as possible. But that’s what I care about in terms of tradeoffs. Others might decide differently.

3 Likes
30

I think Tailwind was put on a throne :wink:

From my understanding, Supabase is also just plain Postgres. You don’t have to use any of the bells and whistles if you don’t want to – and in any case, Supabase extensions are also open source.

Is it possible that people in the Elixir/Phoenix community see Supabase as competition since it offers such a streamlined way to create web applications, and that this is why it isn’t given more love?

The fact that Supabase offers features you don’t have to use shouldn’t count against it (unless it makes the price unaffordable, which I don’t think is the case).

31

But let’s say I just want basic Postgres. Why would it be more sensible to recommend Superbase? Why is my situation considered an “unusual scenario”?

32

It would be sensible because you just get basic managed Postgres – and it costs about $100/month less than CrunchyBase. My point is that you don’t have an unusual scenario, so you should just go with Supabase. Why pay more and get less?

33

Oh are you saying it’s more sensible to use Superbase instead of CrunchyBase? Or in general Superbase is the most sensible solution out of anything when you want basic Postgres?

34

I’m saying both. Supabase seems like the most sensible solution from any perspective.

35

Are you talking about this: GitHub - supabase/supabase: The open source Firebase alternative.

This is the status in the readme:

Public Beta: Stable enough for most non-enterprise use-cases

If you are talking about the same thing, I’m not sure I would recommend that as the most sensible choice for companies doing serious business™.

36

I guess when I think of “enterprise,” I think of really big companies and scenarios in which there will potentially be millions of users. If that is what you mean by “serious business,” then I guess you should consult your CTO.

But for those of us trying to make real money from apps that are built by a team of 3-4 people and aiming at having thousands of users, Supabase seems like the go-to solution.

37

That’s not what it’s saying though. It’s saying it’s “stable enough for most non-enterprise use cases”. Even if you are not an enterprise, why bother with a beta release if you don’t want their other features? To save $100 a month? If money is that tight you could turn off the lights one afternoon a month.

Supabase seems like the go-to solution*.

*for your team

Also something you said about “why pay more to get less?”. That’s one way of looking at it. Another is “why not buy just what i need so I don’t have to concern myself at all with the other bells and whistles that I’m not interested in?”

38

Another thing to consider is Crunchy Data is a major name in the Postgres space with several major contributors working there. If you only care about Postgres that is not something to sneeze at.

39

Supabase has raised $115 million and they have big ambitions. I guess they’re keeping it in public beta until they achieve some more milestones — but that stuff has to do with the bells and whistles and extensions that we’ve all agreed to ignore for the sake of this discussion.

You always have the option of using Supabase as plain, but managed, Postgres.

No one in this thread has yet given one good reason not to use supabase. Your latest objection amounts to “as soon as they’re out of public beta they’ll be the best”.

And don’t forget that supabase solves auth for you as well.

I just don’t get the hate for Supabase and I still think it is best explained by this community seeing it as a competitor.

I see Supabase as a boon for Elixir/Phienix in that it will just make developing Phoenix apps easier and better.

40

You do not own your data, that’s a dealbreaker for a lot of companies.

Don’t get me wrong, supabase has a ton of niceties, but if you’re using it only as a managed postgres they don’t have the edge anymore and there’s companies that offer solutions that are more attractive to specific needs of each team.

I’ll resist my desire to be sarcastic here and just say that authentication isn’t really a solved problem unless you have a VERY flexible system that can handle all the minor details that can show up in your needs, so yeah, supabase handles a small subset of authentication that are useful for some kind of apps, not every app.

Not really, data is a sensitive subject and being on the skeptical and conservative side is a good idea, and even supabase realtime is written in elixir.

Do not confuse being cautious with hating, I personally think that supabase is awesome, but is not the solution for every problem and definitely wouldn’t want it to be the recommended way in the official documentation, specially with something so important as data.

3 Likes