Why I moved Postgres to Render
Arkah needed fewer of Supabase's features, and moving the database to Render meant a fast internal network hop and one less dashboard.
Supabase felt built for a lot of things Arkah didn’t need from it. Auth, functions and realtime were extra capabilities around the database. I wanted Postgres, and I wanted one less dashboard to maintain.
Supabase provides a full Postgres database, alongside those other services. Moving to Render kept Postgres in the stack. The decision was about where to run it and how much of the surrounding platform Arkah would use.
Speed was another reason. Render’s internal network hop felt very fast in Arkah. I don’t have a measured before-and-after result to include here, so that observation has to stay specific to this setup.
Render supports private connections from a web service to Postgres in the same workspace and region, subject to any environment isolation settings. Postgres supplies an internal URL for that connection. Those requirements matter when considering a similar move. Hosting two services with the same company doesn’t, by itself, put them on the same private network. Render’s private-network documentation describes the boundaries.
The extra Supabase features weren’t reasons to keep the database there. Arkah already had its own choices for the jobs around Postgres. Authentication, for example, remained with Firebase Auth. Adopting more of the Supabase platform would have been a separate decision.
The dashboard was the less technical part of the choice, and it still mattered to me. Keeping the database on Render reduced the number of places I had to maintain. That’s easy to leave out of a feature comparison, especially when the alternative offers more things on paper.