You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Skip the default heroku-postgresql addon if DATABASE_URL is set #1068
Currently the Python buildpack's bin/release step sets a default heroku-postgresql addon if the app has a manage.py script.
However for use-cases where the app wishes to use a different Heroku addon, or a non-Heroku DB, this default addon at best is unused and at worst causes confusion.
To resolve this the buildpack could skip the default addon if DATABASE_URL were already set at the time of the first build.
This would cause the default addon to be skipped if either:
the app had another addon attached prior to the first build (that provided the DATABASE_URL env var)
DATABASE_URL was manually set (eg via review app apps.json env list) then the default DB would be skipped
Note: The buildpack API does not provide the env dir location during release. As such the env var would need to be checked during bin/compile and either stored until bin/release, or else the release step refactored such that the payload is generated during bin/compile and saved to disk, and then bin/release simply returns the already-generated payload. The latter is what the Ruby buildpack does.
I'm leaning towards sunsetting the DB auto-provisioning behaviour entirely (tracked at GUS-W-19247777), given new Heroku accounts no longer get this functionality (xref https://devcenter.heroku.com/changelog-items/2596), plus it's also not supported by the CNB. So continuing to support it for the classic buildpack only leads to an inconsistent experience. (And now that there are no free Heroku Postgres plans, automatically provisioning a DB makes less sense.)
Activity
git2gus commentedon Sep 18, 2020
This issue has been linked to a new work item: W-8098790
runjoerun commentedon May 9, 2024
+1
edmorley commentedon May 9, 2024
@runjoerun Hi! Could you explain a bit about your use-case?
edmorley commentedon Aug 4, 2025
I'm leaning towards sunsetting the DB auto-provisioning behaviour entirely (tracked at GUS-W-19247777), given new Heroku accounts no longer get this functionality (xref https://devcenter.heroku.com/changelog-items/2596), plus it's also not supported by the CNB. So continuing to support it for the classic buildpack only leads to an inconsistent experience. (And now that there are no free Heroku Postgres plans, automatically provisioning a DB makes less sense.)