Anyone used Phoenix + Supabase?


I’m wondering if anyone has made a project using for the database layer.

Supabase is a backend as a service which provides storage, user management, authentication and more.

I recall it’s built with Elixir, or at least some pieces of it.

However oddly enough looking at the examples page and available client APIs, Elixir doesn’t seem to be on the list .


I think it’s targeted at frontend devs as a replacement for some of backend functionality, hence the firebase mention.

You can utilise the same tech-stack in your phoenix app as the supabase server, I think there were some recent commits that make it possible to subscribe for logical replication using postgrex.

1 Like

What i’d like to do is use supabase as my database.

It seems a bit roundabout to use supabase from an Elixir application, but you can issue requests to postgrest with http and listen to supabase realtime notifications with a phx channel client.

Basically you’d do

elixir -http-> postgrest -sql-> postgres -wal-> supabase/realtime -phx-> elixir

instead of

elixir -sql-> postgres -wal-> elixir
1 Like

They actually discussed in this podcast the other day (#073 Elixir at Supabase with Paul Copplestone - Thinking Elixir) about not having example for elixir. But as mentioned here, since you already use elixir/phoenix you get a similar offering, where as, their main market is frontend (ie. react) so competing against Firebase.

Also, thinking elixir does some great podcasts: Podcast - Thinking Elixir


They could have digged a little deeper there in the podcast.
As I understand it, it may still be valuable to use supabase from Elixir because you get easy and robust multi tenancy. On the other hand it may not be be worth it because supabase has to charge you for all the great features that are only interesting for Jamstackers. Supabase is (obviously) more expensive than a postgres instance on AWS for example.

It seems to me like Supabase might be worth using from Phoenix just because it provides an authentication system Auth | Supabase


So, pg replication can be used like notify/listen?

It’s better because LISTEN/NOTIFY messages have a size limit. Of course, you can chunk messages, attach an identifier to each chunk, buffer and reassemble them in your application.

What @ruslandoga said is the answer.

I’m using Cainophile to listen to the Postgres wal and bust caches, as an example. It’s awesome. Today you’d probably want to use Postgrex.Replication and then decode the messages with Cainophile.

Almost everything that Supabase is doing you can do with just Postgres. Although, as of last week realtime supports row level security. walrus is what does that. But yeah even though realtime is powered by Elixir and Phoenix the dev story for Elixir folks is not there.

They are definitely targeting front-end devs who typically don’t have the ability to easily connect directly to the database. So instead of writing your API in Node you just spin up a Supabase instance and automatically have an API generated for you based on your Postgres schema. Auth is another difficult thing for most people so providing an easy solution for people is important for adoption (it’s one of the reasons Firebase became so popular).

Yeah you wouldn’t want to use the HTTP interface they expose to access Postgres when we have direct connections.

There is I think a max of 10 replication slots for Postgres so if you have a larger cluster it might make sense to use Supabase to listen to the wal over Pubsub.

It’s fully open source too so if you do want to play with it you can spin it up yourself.


1 Like

@chasers, it looks like is joining forces with Supabase (according to their blog)?

I’ve actually extracted out the WAL listening stuff from Supabase Realtime (which is based on Cainophile) into a package: GitHub - cpursley/walex: Listen to change events on your Postgres tables then perform callback-like actions with the data

I’ve been using this along with Hasura (Supabase wasn’t around when I started) so that I can handle business logic right in Elixir. The main differences are that I’ve added a supervisor to process Events and I’m casting to Elixir types instead of Json.


Cool, I have a small demo I made using listen notify + phoenix channels when I was trying to wrap my head around listen notify. I copied most of the code from a blog post that serialized the events into a json before notifying it, with replication I dont need to serialize the data right?

Another question, is this a good feature to use as a foundation for an auditing library?
A few days ago I complained about having to deal with how most auditing is done on rails land (using model callbacks) and on a first glance this looks like a perfect solution for that.

You still need to deserialize it from the binary stream into a term, and then if you send it through channels you have to turn it into JSON (or some other binary as long as the client can decode it).

There is wal2json which pushes the decoding and serialization onto the database server.

100% I think it’s the right choice. You just monitor changes in one place. Any change to the db you know you’ll see.

As long as you have somewhere to store all the change data. BigQuery is a great option for that, or Clickhouse, Timescale. If it’s not changing all that much you can use another table (just don’t track the changes for that haha).


Yep! Been meaning to post something here actually.

:eyes: I’ll check it out. Sounds like you have a great setup!

I will try to find some time on the next weekends to play with this idea.

It occurs to me that if you use Supabase for your database layer, then you not only get an auth system, but you also get multi-tenancy. So this effectively makes your app simpler and more flexible.

Supabase costs $25 month, and that’s about what you have to pay just to get off the ground with a decent Postgres hosted solution for a Phoenix app anyway.

How is Supabase not just a hands-down winner here? If your app needs a Postgres database and your app needs to authenticate/authorize users, then shouldn’t Supabase be the go-to choice? What possible benefits are there to just going with a Postgres installation that doesn’t bundle an auth system?

Pretty sure supabase gives you API endpoints so you’re no longer using ecto to interact with a database. I assume you give up a lot of control over the database. That might suit some people but not others.

From looking into it, it is not clear to me that you give up any control over the database – at least any more so than with any other hosted Postgres solution. But I would be interested if someone can point to something specific. I don’t understand what is wrong with API endpoints – isn’t getting those for free a good thing?

Well you might not need them. But you’re right, you do get normal DB access in addition to the API endpoints.


can you elaborate a bit more about that part of your posting?