Applications and operations
Choose where PostgreSQL runs
Compare a managed service with operating PostgreSQL yourself before treating the monthly price as the whole cost.
Everything in this course so far ran on your laptop, and for development that is the right answer: fast, free, and yours to break. A deployed application needs a database reachable from wherever the application runs, and that is a real decision.
You have two families of options, and the difference between them is not features. It is whose pager rings.
Managed PostgreSQL
A managed provider normally handles installation, patching, monitoring, backups, and failover options. You get a connection URL and a dashboard; the provider keeps the server alive.
You still own schema changes, queries, access, capacity, and restore testing. No provider knows that your notes table needs an index on user_id, or that the runtime role should not own tables, or whether last night’s backup actually restores into something your application can use. The lessons in this course stay your job on every host.
Managed costs more per month than raw compute. What you are buying is the operational work you no longer perform, and for most small teams that trade is worth it.
Self-hosted PostgreSQL
Self-hosting gives more control but also makes upgrades, storage, replication, security, and recovery your responsibility. On a $5 VPS you can run PostgreSQL next to your application and pay almost nothing.
The monthly price is not the whole cost. Price the hours: securing the server, applying updates, planning major-version upgrades, watching disk space, and rehearsing restores. If that work excites you, self-hosting is a great teacher. If it sounds like a distraction from your product, it is.
Choose the operational work you are prepared to perform, not only the database feature list.
Questions that decide it
A few concrete checks beat any comparison table:
- Can you restore yesterday’s backup right now, and have you tried?
- Where must the data live, and does the host’s region satisfy that?
- Does your platform run serverless functions? Those multiply connections, so a host with a built-in connection pooler saves you pain.
- What happens when the machine dies at 3am, and who notices?
Whichever way you choose, run the same verification: take a backup, restore it into a scratch database, and point the application at it. The failure mode of hosting decisions is assuming somebody else tested recovery. Providers back up; only you can prove the restore feeds your application.
Lesson completed