Co-locate web service region with DB + Supabase pooler hardening#27
Merged
Conversation
- render.yaml: add `region: oregon` with a note to match the database's region (Supabase "West US" = oregon). Without this the web service defaults to Oregon while a student's Supabase project may be elsewhere, causing slow cross-region queries (observed ~2.5-4.7s vs ~0.3s when co-located). - database.yml: set prepared_statements: false and advisory_locks: false for production. Harmless on the Supabase session pooler (5432); prevents a silent `db:migrate` hang if a student uses the transaction pooler (6543).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Two small deploy robustness fixes surfaced while deploying a data-backed Rails app via the Render Blueprint + Supabase flow.
1. Region co-location (
render.yaml)The web service had no
region:, so Render defaults it to Oregon (US-West). If a student's Supabase project is in a different region (e.g. East US), every query is a cross-country round-trip. Measured on a real app: ~2.5–4.7s of DB time per page vs ~0.3s once the service was moved to the database's region.Added
region: oregonwith an inline note to match the database's region (Supabase "West US" =oregon).2. Supabase pooler settings (
config/database.yml)Added to
production:These are harmless on the session pooler (port 5432) the lesson recommends. They become necessary on the transaction pooler (port 6543) — a very common URL mix-up — where
db:migrateotherwise hangs silently forever acquiring its advisory lock. This makes the template robust to either pooler URL.No behavior change for correctly-configured session-pooler deploys.