A backup you have never restored is a hope. The two numbers that define a backup plan, which failures each kind of backup covers (including a compromised account and a bad migration), the RDS retention defaults that surprise people, and a quarterly restore drill that takes an afternoon.
Two numbers define a backup plan. RPO (recovery point objective) is how much data you can afford to lose, measured in time. RTO (recovery time objective) is how long you can afford to be down while restoring. Write both down. They decide everything else.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
RDS keeps automated backups for 0 to 35 days. The default is 7 days in the console but 1 day from the API or CLI, which is what most infrastructure tools use. Zero turns backups off.
Automated backups are what make point-in-time restore possible within that window.
Managed Postgres platforms vary by plan in retention and whether point-in-time restore is included. Check yours.
Turn on deletion protection for production databases and keep a final snapshot when deleting anything.
For files, turn on S3 Versioning so overwrites and deletes can be undone.
Once a quarter, restore production's backup to a new, separate database.
Time it from start to a working app pointed at the copy. That is your real RTO.
Check the data: row counts, the newest records, a few known accounts.
Write the steps down as you go. The person restoring during a real incident will be stressed, and may not be you.
Delete the copy.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Too Many Connections: Database Pooling for Serverless and Edge Apps
Postgres gives every connection its own process and a fixed maximum, while serverless platforms create a new instance, and a new connection, for each concurrent request. The result is the classic launch-day error. How the limits are set on RDS and Supabase, what a pooler does, and the transaction-mode catch.
Read
Row-Level Security: The Check Between Your Users' Data and Everyone Else
Apps on Supabase, Firebase and similar platforms let the browser talk to the database directly. That is fine only if the database enforces who sees what, because anyone can call the same API without your UI. How row-level security works, the gaps that catch people (views, functions, storage), and a ten-minute test.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.