Branching - Early access | Feedback discussion

[MildTomato]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

Vote for hosting provider integrations here and Git providers here.

[bitnom]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

What is Supabase Branching?

[MildTomato]

In the most concise sense, you can use branching to safely and easily experiment with changes to your Supabase projects.

You can check out the docs here.

[KajSzy]

Is branching expected to be available only from Pro plan or will it be availbe on free tier?
If I decide to upgrade to Pro plan today, will I be able to use branching immediately?

[MildTomato]

@KajSzy We've currently closed the Early Access programme for Branching. If you have already upgraded expecting access, if you could send in a support request and we'll look into it 😄.

I think some of our docs have not been updated to make it clear that it's in private early access, and we've now closed accepting any more requests. I'll update the docs today to be more clear.

[skarard]

Hope you're all doing great! I've been working with supabase on a project for 2 months and noticed something I wanted to share with you that would cause issues for supabase branching. As our projects grow, our seed file (you know, the trusty seed.sql) can become a bit of a beast. We're talking thousands of lines that make you not want to open it up again. In my case, it has ballooned to over 10K lines! Runs pretty fast, sure, but it's a bit of a headache to manage and scroll through.

I've been sidestepping this by ditching the massive seed file and scripting my local database seeding instead. It's a lot like how migrations work: each file is timestamped and has a quick description, and they run in a set order. This means I have separate files for different seeding needs, like permission tables and location table inserts broken down into 1K-insert chunks – it’s pretty neat.

Currently, Supabase runs whatever is in seed.sql and that's that. But here’s a thought: what if branching could also run all the timestamped files we've got in a seeds folder? I think that'd be a game-changer for many of us, making life a bit easier and our projects tidier.

I reckon this could be something worth considering for your roadmap for seeding a branch.

Thanks for all the hard work you've been putting into Supabase, and I'm excited to see how branching evolves!

[MildTomato]

Neat idea.

I also mentioned this to @sweatybridge who is one of the developers managing our migration/seed runner.

I suppose it would have to be timestamped for it to work correctly. Do we know of any other tools doing this? We can't be the first ones to think of this? 😊

[skarard]

To be honest I took the idea directly from my experience of working with the ORM Sequelize. Here is a relevant documentation that mention both migrations and seed files: https://sequelize.org/docs/v6/other-topics/migrations/

One thing to note is that their migrations have an up (which is covered by seed.sql) and a down that is not covered by supabase. The down function is if you are to roll back a migration including any data manipulation that was required to complete the migration. It's very useful when you can't predict how a project will evolve once it's in front of users. Sequelize also handle transactions in their migrations, which makes migrating production databases a lot less intimidating.

[MildTomato]

There is a similar discussion to this here as well now 🙌

[chaos128]

if new branch is created, new Supabase url for client is reserved on new branch??

I maen if I use following url on main branch
const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key')

Can I use a different url for a new branch like staging? For example,
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

[MildTomato]

How it works today is a bit like that but it's the id string in the middle that changes.

main branch (production)

const supabase = createClient('https://spztrrugbkgdayfejlvi.supabase.co/', 'public-anon-key')

the feature branch your working on will then have a completely different id in the url

const supabase = createClient('https://qrelykancvxikefwrefd.supabase.co/', 'public-anon-key')

I could understand if this might not be useful in some circumstances, as it makes it harder to build urls based on git branch name in maybe your client or server app.

The problem extends to API keys though as well, since every branch in Supabase has it's own unique set of API keys, db password and so on.

What do you think @chaos128 ?

[chaos128]

It would be okay but I think it would be a little bit inconvenient. It would be better if domain and key are not changed but only pathname is changed based on branch names like I said on question.

main branch
const supabase = createClient('https://xyzcompany.supabase.co/', 'public-anon-key')

staging branch
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

feature/test branch
const supabase = createClient('https://xyzcompany.supabase.co/feature/test', 'public-anon-key')

[MildTomato]

That's interesting. Can see that being a lot more useful and easier to use.

Also the keys not changing between Preview Branches is interesting as well - we were mostly concerned with Production and Preview being isolated and concentrated efforts on that and hadn't really investigated on making it easy to switch between Preview branches with predictable URLs and consistent keys. Great suggestion.

[MildTomato]

@chaos128 how are you using Supabase Branching?
are you running your app locally and trying to easily connect to correct Preview Branch?

[rorysaur]

Chiming in here because I would also love to see predictable URLs and consistent keys.

We have a Next.js app on Vercel, using Prisma. Our current workflow, without Supabase branching:

Our branch main syncs to our Vercel staging deployment and uses our Supabase staging db. Our branch production syncs to our Vercel production deployment and uses our Supabase production db. We have a GH action which, upon merge to either of these, runs prisma migrate against the respective db, using creds stored in GH secrets.

That means preview/feature branches create Vercel preview deployments, but have to stay unmigrated (except for staging itself), since we don't want to mess up the staging db before merging to main. So features requiring migrations can't be tested on a preview deployment.

If we turned on Supabase branching on our staging db, I'm picturing that it could work for preview deployments if the app and, separately, the GH action, can both get or construct the branch db's URL/creds (actually we use the full pooler URL) from env variables that are available. And then we'd have the GH action migrate the designated branch db upon branch creation. So a completely new set of URL/creds seems hard to deal with in this scenario, whereas some combination of base URL (already set in Vercel and GH) plus the branch name (already easily available in Vercel and GH) would be very doable.

I see someone else who posted has a similar setup with some steps to make it theoretically work in the GH action.. but it seems to rely on CLI commands, and I'm not sure if that would work for getting the Vercel preview app to also point to the branch db.

(Update: I also just realized Vercel support is in development which would solve the Vercel half.)

[sudonymously]

Can branching be used as a "dev" environment?

[MildTomato]

Yep. What's your use case? Can you tell us more?

[kishanhitk]

According to the docs: "The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it."

But when I deleted and recreated the branch (dev), it does not recognise the existing PR from that branch.

[kishanhitk]

EDIT:
The branch migrations are being applied as expected. Only this UI on the dashboard is not being updated properly.

[MildTomato]

That's probably a bug. We are using github webhooks and I think it only adds the PR metadata to the Preview Branch when a PR is opened (there's a webhook event for it) - but that makes it impossible for a new Preview Branch to then be associated with a PR later; like when you've made a new Preview Branch.

I think we could fix that. Everything should work as normal though, it's only the UI here that's been impacted.

[0xBigBoss]

So far pretty good with supabase branching. Should I disable my existing github actions that migrate the production database when merging to the production branch? Is it expected that the migrations should be applied via this new Supabase branching integration?

reference https://supabase.com/docs/guides/platform/branching?making-updates=local-dev#merging-production-changes

[MildTomato]

It's worth stressing first that Branching is not suitable for production based apps right now.

With that in mind, and if you want to continue; yes, you should be able to merge your feature git branch into your 'production' git branch and it will run the new migration files against the Production Supabase branch. There is currently no way to turn this off, so it's probably advised to disable your github actions.

[huyouare]

@MildTomato are there known issues we should watch out for w.r.t. production? Or is it just that more time is needed to bash the bugs out that in theory could harm a prod instance?

[blechatellier]

@MildTomato does supabase branching support monorepos? Our supabase/migrations folder is in a subdirectory (ie: apps/database/supabase/migrations.

[kamilogorek]

Changing a path which /supabase is pulled from is on our roadmap. However as @MildTomato already mentioned, we need to rethink how it works first, to allow multiple Supabase projects to read from a single repo (eg. your monorepo usecase) or any other variant of one-to-many/many-to-many connections.

[tristdrum]

Yeah would love to see this sort of mono-repo support! Very excited for you all to start using branching on internally too!

[donjpierce]

I would also require the mono-repo support for my project with a custom path to my migrations folder. Big fan of this branching feature and how it is progressing!

[kamilogorek]

The code for it is already written and we're going to test everything in upcoming week :)

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[mosnicholas]

any advice on how to handle issues like this that require setting up things in the database (eg. webhooks)?

[danielgwilson]

Any updates here? This is preventing us from using branching

[danielgwilson]

@MildTomato

[blechatellier]

For what it's worth, I have been running into so many issues with branching that the best solution for us was to manage the full lifecycle using a custom github action leveraging the management API.

[danielgwilson]

@blechatellier that may be what we have to end up doing—would be a shame

[blechatellier]

To be fair, hard for them to come up with something that will work for everyone - it's been the best decision and took a couple of days to get it to work.

[hyldmo]

Hello! Loving the concept so far. After spending some time working around issues (seeding not being run and functions not being deployed), I realised you have a CLI for managing branches (which looks great btw!), and I think it could be highlighted more, as I was under the impression that only the "managed" workflows were supported (i.e only Github + Vercel), but atleast for me the feature set is complete enough that I could run this anywhere (and if i missed that that was possible, many others probably have too)

[MildTomato]

Just checking, as we need to improve our documentation:
Did you follow this guide regarding preparing your repo?

[sleakchat]

@hyldmo How did you manage to work around the issue of webhooks not being able to deployed in preview?

I'm experiencing a similar issue, when migrating everything migrates succesfully except for the existing database webhooks:

Connecting to remote database...
Applying migration 20240413231739_remote_schema.sql...
ERROR: schema "supabase_functions" does not exist (SQLSTATE 3F000)                                                                                                                                                                                                              
At statement 80: CREATE TRIGGER "new_kb_topic" AFTER INSERT ON "public"."kb_topics" FOR EACH ROW EXECUTE FUNCTION "supabase_functions"."http_request"('my-url', 'POST', '{}', '{}', '5000')
Try rerunning the command with --debug to troubleshoot the error.

[venku122]

+1 I am also running into this issue.

I went to /database/hooks on the preview branch and enabled webhooks.
Retriggering a deploy did resolve the issue.

[sweatybridge]

My "dream" CI workflow would work something like this:

1. Run supabase branches create $BRANCH_NAME
2. Get project ID from newly created supabase branch
3. Use project ID run regular steps:
4. supabase db push/reset
5. Run codegen off branched supabase instance
6. Run linting / formatting / unit tests
7. Build and deploy frontend with project ID
8. Deploy supabase functions
9. Verify env with E2E tests

If you are willing to manage your own GHA for setting up branches, all of the above are currently available through the terraform provider. We have an example repo here for those who want to tweak and use https://github.com/supabase/supabase-action-example/blob/main/.github/workflows/preview.yaml

I went to /database/hooks on the preview branch and enabled webhooks.

For webhooks, we will look into enabling by default for all new projects and branches.

[danielgwilson]

@sweatybridge any updates on Webhooks?

[DamonGuzman]

We are in dire need of selecting non root directories as the Supabase root. We are using a monorepo with TurboRepo.

[kamilogorek]

It's coming. Bear with us some more time, we're getting there :)

[DamonGuzman]

That's great news! We just finished building our own internal psuedo-branching by creating a new project on every PR. It was quite difficult to implement correctly since there was a silent failure when connecting via IPv4.

Do you have any rough estimation on timelines?

[kamilogorek]

We're hoping to release this month, but I don't want to be held accountable for any specific date just yet.

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[sidharthv96]

Currently, we're testing each branch by setting up a local supabase instance in GH Actions for every run. But that setup takes a significant amount of time compared to the actual test run.
So we're looking for a way to accelerate the setup process, using branching.
We have our seeding script in TS, and are using Prisma for migrations, and use Vercel for deployment.

The flow that we have in mind is:

1. Inside GH Actions, on PRs
2. List all branches using supabase CLI
3. Create preview branch if required
4. Get the details of the preview branch using CLI (URL, API key, etc.)
5. Update our .env file with the details, clear, migrate and seed the database (to be consistent across runs)
6. Run the tests
7. When PR is merged, use supabase CLI to delete the preview branch

Are there any blockers that we should be aware of?
Is there a better way to do this?

Moreover, once this is set up and the Vercel app is used, I'm assuming the preview instances will use the new branched supabase.

We also don't want any changes in the preview branches going back into main (which I assume will not happen as we are not using supabase migrations in the preview branches). Can you please confirm this?

[sweatybridge]

which I assume will not happen as we are not using supabase migrations in the preview branches

Yes that is correct. The Supabase GitHub integration only look for files in supabase/migrations directory. If it is empty, no migrations will be run.

Overall your approach sounds sane to me.

We will need to make some changes for step 2 and 3 so that you can fetch a preview branch by its git branch name. Otherwise the current workaround is to parse the output from branches list command to extract the branch id. Then use pass the branch id to branches get command.

You might also need to handle retries in step 4 until the status of your branch database is ACTIVE_HEALTHY.

I think step 7 is not required if you use the Supabase GitHub integration. Because we delete the branch on PR close.

[thedevdavid]

Feedback/idea: It'd be nice (or even crucial) for the preview branch to copy most local and/or production branch settings.

Examples:

• custom email templates (because you need to customize them for Next.js SSR)
• use the production API endpoint with a subdomain or route for preview branches
• auth site & redirect URLs
• auth provider settings
• project auth settings (custom SMTP included)
• upload size limit
• edge function secrets (or at least some prompt to set them)

[Tananga]

This is a must have

[MarkBennett]

Given the branching is meant to correspond with git branches, perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

That would let teams modify using their existing git workflow, and handle these decisions there?

[sweatybridge]

perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

This sounds like a configuration as code proposal. We have a terraform provider example where all the auth and api settings are committed to git. https://github.com/supabase/supabase-action-example/blob/main/supabase/remotes/preview.tf

In the long run, we probably want to support copying configurations from base project so that we don't explicitly depend on terraform in the infrastructure.

[empz]

Any updates on this? Without the Auth provider settings this is unusable as we have to go over and manually enable providers for each preview branch to be usable. Because auth provider settings are not stored in the database, or are they? I mean, we couldn't set them in a migration.

[Keeghaan]

Any updates ? This idea is really necessary

[ronthedrummer]

For some reason I'm not seeing migrations running or seed data populated for a preview branch (feature or development). When I create a PR, it's spinning up the branch, just no tables or seed data.

[kamilogorek]

When creating a new branch on Github, it doesn't mean I want to create a new branch on Supabase automatically. Only when there are changes in the ./migrations folder I'd say. Or make that arbitrary.

Done, you can use it today.

Option to have the data populated in an easy way

There is basic seeding capability already with seed.sql file, but we want to add better integration with Snaplet or similar tool as well in the future.

[morasaek]

Whenever I merge branches, the branch disappears. I think this might be useful when working with feats, but when you want a permananent staging branch, it's not desired.

+1(00) on this point!

[RobSchilderr]

They say the best way now is to create a separate Supabase project for the staging branch.

[kamilogorek]

Q: We have few ideas how to go around it, but just to get a feel for it in public, wdyt is your preference in regards to long-lived branches?

• hand-pick already existing branches to be persisted, eg. on branches page - https://supabase.com/dashboard/project/_/branches
• change the setting to be applied for a whole connection on - https://supabase.com/dashboard/project/_/settings/integrations
• have a connection setting where you can list branch names to be persisted
• other approach?

[huyouare]

Adding a data point: we are using a separate project for Staging + Preview branches, while keeping our original project for Production only (same as @RobSchilderr's post above). This seems to work pretty well for persisting Staging so far, though it's not 1:1 with the Vercel style of branching.

[amitav13]

We handle our migrations via Prisma migrate. Are there any plans to support the migrations folder generated by this? Or any workarounds at this point?

[kamilogorek]

Currently you'd have to move file to migrations directory inside ./supabase, but that's a good improvement for the future. Thanks

[amitav13]

Would just moving the folder work? The migration files/formats are directly compatible with supabase?

[kamilogorek]

Yes, the migration file is always just a smallest sql snippet that will result in the desired schema shape at the end of execution.
They are usually tracked via sorted list of migration files, that are stored in _migrations (or similar) table.
The only difference here is that prisma expects migration files path to be migrations/data_name/migration.sql file, eg migrations/20210313140442_init/migration.sql, where Supabase expects migrations/20210313140442_init.sql, which means that you'd have to do something like code below to copy, rename and put them in correct place in one go.

find . -type d -depth 1 | xargs -I{} cp {}/migration.sql migrations/{}.sql;

[amitav13]

Got it. A cleaner way built in to supabase would be nice! Especially since there's a pretty large audience (I'm assuming) of supabase TS users using prisma.

[aliyeysides]

Here's a bash script for those that want to copy Prisma migrations to a supabase directory:

#!/bin/bash

# Define paths
PRISMA_MIGRATIONS_DIR="./prisma/migrations"  # Replace with your Prisma migrations directory
SUPABASE_MIGRATIONS_DIR="./supabase/migrations"  # Replace with your desired Supabase migrations directory

# Create the Supabase migrations directory if it doesn't exist
mkdir -p "$SUPABASE_MIGRATIONS_DIR"

# Function to convert Prisma migration files to Supabase format
convert_prisma_to_supabase() {
  for prisma_migration_dir in "$PRISMA_MIGRATIONS_DIR"/*/; do
    if [[ -d "$prisma_migration_dir" ]]; then
      migration_file="$prisma_migration_dir/migration.sql"
      if [[ -f "$migration_file" ]]; then
        migration_name=$(basename "$prisma_migration_dir")
        supabase_migration_file="$SUPABASE_MIGRATIONS_DIR/$migration_name.sql"
        cp "$migration_file" "$supabase_migration_file"
        echo "Converted $migration_file to $supabase_migration_file"
      fi
    fi
  done
}

# Run the conversion function
convert_prisma_to_supabase

echo "Migration conversion completed."

[UmashankarSpeckyfox]

Hey Folks

I want to Setup a Supa Base Branching for the Automation Testing so the scenario is Below
I need to Setup the CI/CD pipeline for the Automation Project. Pipeline is already exists but i need to run my tests in between build and Deploy. So i want to use a Supabase branching to run my automation scripts on supabase temporary branch.

So how i can do it can anyone help me out in this

Thanks in Advance.

[stefkudla]

Loving this feature so far. I know that the default is to keep preview branches not persistent and to delete them once a PR is merged (better for cost and saving on resources), though I think it would be nice to have an indicator or toggle when creating the branch because I had no idea they weren't persistent until I merged my staging branch into production.

[kamilogorek]

Hmm there is a toggle and an indicator in the UI https://supabase.com/blog/branching-publicly-available#persistent-branches

[stefkudla]

Hmm, not when creating the branch

[Intuvo]

Hi, it wont let me enable SSL for my preview branch

[Intuvo]

Failed to update SSL enforcement: failed to update ssl enforcement config

[Intuvo]

tried through the CLI

failed to update SSL enforcement confnig: {"message":"failed to update ssl enforcement config","errorEventId":"de85e5e25d4a4c6f9ab572f2a16fc0d4"}

also an interesting spelling mistake in that error.

[kishanhitk]

Getting error: Failed to update Github connection: Project reference is missing when validating permissions
when trying to change the base directory for supabase.

[kamilogorek]

Fixed 🙇

[wusixuan0]

I'm seeking clarification on the best practice for implementing Supabase branching in my project. The documentation warns against using branching in a "production setting," but also describes merging branches within a single project. I'm unsure whether I should create two separate Supabase projects (one for production and one for development with branches) or use a single project with a main "production" branch and separate development branches. My app is still in the development stage, but I want to set up a proper workflow that separates development and production environments while leveraging the new branching feature. How should I structure my Supabase project(s) to best utilize branching while following best practices for development and eventual production use? Thank you so much for your help!

[wusixuan0]

I think I found the correct answer from Supabase docs

• docs warns against using the Branching feature in a production setting, and recommends using Migrations to manage changes to your production database.
• it is recommended to have separate projects for development and production environments in Supabase. 
• Branching is an early access feature for test and preview changes.

[manish-onefinitylabs]

@MildTomato: Can you confirm if this is a more dependable way ?

[blechatellier]

Is there a way to get the full database url / pooler url, project url, anon key for a specific branch via the CLI? When using supabase branches get it gives partial information and the host / user are wrong.

[kamilogorek]

@blechatellier currently it's only possible using the API directly https://api.supabase.com/api/v1
Feel free to post an issue at https://github.com/supabase/cli for a feature request.

[dewinterjack]

I'm getting this error when trying to set up branching: failed to run supabase --workdir=.: 1
I have confirmed the supabase directory is in the root of my repo. This is our first time setting up branching

[icopp]

Same problem here. All migrations work locally, but the GitHub check entry for Supabase Preview just shows

failed to run supabase --workdir=packages/supabase: 1

and the only logs shown are

Cloning git repository...
Migrating project database: (id here)

I think this may be rebase related in some way. Each time I've done a force push with rebase changes (merged/deleted/rearranged commits) on a branch, it errors out like this. But, for any new commits added after that, it runs successfully.

[icopp]

After some further testing, it's definitely the rebase issue. Even adding an empty commit after a rebase that changed stuff and pushing again makes it work on the following run.

[felipe31]

I've got the same issue, but adding a commit would not fix it.

[truetrev]

I've got the same issue, but adding a commit would not fix it.

Did you ever figure this out. I'm adding a commit and it's not fixing it.

[luizmiranda7]

I got the same issue when enabling branching for the first time. Is there a fix for that?

[icopp]

The GitHub integration gets extremely confused if you ever make a PR that doesn't target main/master. It will tell you Reopen this PR to launch a Supabase Preview branch., and even if you retarget the PR to main, the only way to get it to work again is to close and then open the PR again.

[johnford2002]

Lately, we've been experiencing issues with supabase branching not deleting preview branches when PRs are merged. We have our GitHub repo configured to delete branches on merge, so the branch is removed from the repo, but it isn't being removed from Supabase. Further, the variables that supabase syncs to Vercel are not being removed.

Any suggestions on how we can remedy this?

[sweatybridge]

We have identified the issue and will be releasing a hotfix today. Apologies for the inconvenience.

[gc-ft]

I am working on setting up branching and I have seen one issue which might very well be a mistake of mine, but it seems like an oversight to me.

The documentation suggests to Prevent Migration Failures in GitHub. So setting up a Branch protection rule for status checks to pass before merging. Makes total sense to me. However, if my PR now is for changes made outside of the supabase directory, and I have Supabase only changes feature turned on in the branching, then the status simply is not run and therefor GitHub believes it "failed" or rather, waits for it to run successfully.

This seems a fringe edge case, I get that, however if we for example update our README.md documentation or some other files in the root directory of the repository, and want to merge these into master for example with strict rules, thus requiring a PR, supabase integration is going to indefinitely block this PR until I do some arbitrary change inside the supabase directory.

Would it not make sense to still run the status check and simply have it pass so it does not block this kind of PR?

Again, I understand this is a weird edge case, but maybe I also have made a mistake here or there is no way to fix this?

Thx,
Fabian

[danielgwilson]

Same problem just now—temporary resolve is I just turned off "Trigger branch creation only when there were changes to supabase directory.", but not ideal

[gc-ft]

Small bug: If you have more than one vercel project integration, saving does not work correctly. If I change something in the second and press Save there, the Save in the first integration runs. I can not turn off production env keys for the second integration now.

[gc-ft]

Tried PR first time with changes in migrations. Branch Preview is created in supabase, but the migrations fail and the only error I see in the logs on GitHub is:

failed to run supabase --workdir=.: 1

There is a warning also in the GitHub PR comments, however this seems out of my control:

 Warning — Preview branch version (15.1.1.86) does not match production database version (15.6.1.113).

Amy ideas?

Thx,
Fabian

[gc-ft]

My problem was that webhooks were disabled and a create trigger using supabase_functions failed.

I will move away from the internal webhooks logic to my own soon, so that should fix that issue.

However, should the GitHub integration not produce a more intelligent error showing WHERE the migrations actually failed?!

Fabian

[Jullemand]

When setting up my development branch next to my main branch I run

supabase db pull --db-url postgresql:// URL /postgres

Here I then get the following error:

failed to parse rows: ERROR: prepared statement "lrupsc_1_0" already exists (SQLSTATE 42P05)

I have no migration files. I have tried to remove the /supabase folder, /migrations folder, re-init and revert to older migrations when I had some. My supabase CLI is up to date.
Any ideas on what to do?

[kamilogorek]

Can you verify that you're actually using postgresql://...:5432/postgres url instead of a pgbouncer postgresql://...:6543/postgres?

[Jullemand]

Thank you for your fast response two weeks ago.
Your comment solved it, I just forgot to respond! Thank you! :D

[spencer-rafada]

How can I configure Supabase to not show up as unsuccessful action when there are no changes to supabase directory at all?

[gc-ft]

There is an option in settings > integrations under the GitHub integration uncheck the "supabase changes only"

That should work.

How can I configure Supabase to not show up as unsuccessful action when there are no changes to supabase directory at all?

[kamilogorek]

@spencer-rafada I assume you have a required status check configured in this case? As we don't create status checks on our own for not matched PRs.

[slimshreydy]

I need to access my branch DB instance via an old-school connection string (I'm using it with an ORM). It seems like the DB instance has its own separate password, but it's not a password I've set anywhere. How can I locate the password Supabase generated with the branch?

[kamilogorek]

Use https://api.supabase.com/api/v1#tag/environments/GET/v1/branches/{branch_id} to fetch branch configuration. You can find generated password there.

[leon-endex]

How do we increase the compute/memory for supabase preview branches?

[kamilogorek]

There is currently no way to do this, and all branches are running on Nano instance.
Our branching team is working on allowing that and providing custom config for branches as we speak. I cannot give you any specific timeline though here.