DEPLOYMENT GUIDE

Where Should You Host Your Web App and PostgreSQL?

Compare one provider with separate providers, from connectivity to recovery

Should your booking app and PostgreSQL use the same provider? Start by deciding how the app connects to the database and who restores the data after an incident or migration. A small new app can start by looking at a same-provider setup with internal connectivity. An existing database or a specific recovery requirement can make a separate provider a better fit.

In this article

How the connection changes across providers

The web server and managed PostgreSQL are separate resources in both setups.

How the web server reaches PostgreSQL · Conceptual diagram
One provider

Browser → web server → internal database URL where supported

Separate providers

Browser → web server → database provider endpoint

The web server holds the connection credentials in both setups.
Setup Benefit What to check
App and database at one provider Supported services can simplify internal connectivity and configuration Account and region requirements, encryption, backups. Render connection guide
External managed PostgreSQL Choose and migrate app and database plans independently Region, reachability, TLS, and connection count. Neon pooling guide

What to decide for a booking app

Using one provider

Render offers an internal URL for supported services in the same account and region, and an external URL. Review external access restrictions if you only need internal connections. Render connection guide

In KamuiDash, selecting a database when creating the app sets environment variables such as DATABASE_URL. The app reads it at runtime. Keep it out of files committed to GitHub or sent to the browser because it contains credentials. KamuiDash database connections

Using external PostgreSQL

This can suit an existing database or a separate database plan. For a public endpoint, check connection source restrictions and the provider’s recommended certificate verification. Consider nearby regions and measure real list or search requests. Repeated SQL round trips add network wait even in nearby regions. PostgreSQL TLS documentation

Count connections across processes. Two app instances with two processes each and a pool limit of five per process can open up to 20 connections. Add any connections used by admin tools and migrations. If your provider offers pooled and direct URLs, as Neon does, use the connection type your migration tool requires. Neon pooling guide

Test writes and recovery before launch

For a new app, apply the schema, make a booking at the public URL, redeploy the app, and verify that you can still view and edit the booking. Recovery depends on the plan. Paid Render Postgres can restore a chosen point in time to a separate database. The operator verifies the restored data and switches the app connection. Free Render Postgres does not offer this feature. Render recovery and backups

For an app with users, decide how to handle writes during the final copy. If you can schedule downtime, pause writes before taking that copy. PostgreSQL backup and restore

Database migration with a write pause · Conceptual diagram
Pause writesStop the app and jobs that write to the old database.
Copy and restoreVerify counts and behavior in the new database.
Switch the connectionResume writes on the new database.
Plan how to handle new data if you need to switch back after writes resume.

If you are unsure where to start, compare a setup with internal connectivity and simpler operations with one that gives you the database features you need. Compare connection paths, backup retention, and time to restore alongside monthly costs.

See how to publish web apps from GitHub on KamuiDash.