Choosing Backup Retention for a Small Postgres App

Before launching a small order app, your team needs to budget for backups. The Node API uses a Postgres database that holds two gigabytes, and the provider's estimate asks how much backup data you expect to keep. Two gigabytes gives you the size of the live data. To finish the estimate, you also need to know what backups accumulate during normal use and how much it costs to run a restored copy for a test.

Work out how far back you need to recover and how much recent work you can afford to lose. Then estimate the backup storage your provider measures after any included allowance, and budget for the time you need to run a restored database while you check it.

Put the recovery need beside the storage estimate

Use these hypothetical figures to see how a team could price backups for an order app called Parcel.

Because a mistake may take three days to find and another day to investigate, Parcel needs to reach back more than four days. The team starts by checking whether seven days of retention gives it enough room for delays.

Parcel also needs to recover all but an hour of recent work. A backup made once a day could leave almost a day's worth of orders outside the most recent copy, however long the team keeps its daily backups. Parcel needs a recovery option that can reach between those copies or a reliable way to rebuild the recent orders.

Decide these limits before comparing plans. Otherwise, the cheapest row may describe a service that leaves the team unable to recover paid orders.

Measure what the provider stores

Use the provider's reported backup storage. Multiplying two gigabytes by seven days assumes every day adds another full copy, while the provider may store changed blocks, compress backups, or archive logs. Check how it measures usage and applies any included allowance.

Postgres point-in-time recovery starts with a base backup and replays archived write-ahead logs to reach the chosen time. You need both the backup and the logs covering that period. A small database that rewrites many rows can produce more archived changes than a larger database that rarely changes. PostgreSQL archive recovery

For Parcel, measure stored backup bytes after the nightly import and cleanup jobs run, over a period that includes the team's normal weekly work. A reading taken right after creating the database could miss the import that adds most of the storage.

Keep the date, workload, and provider's unit with each reading. If the provider reports usage over time, use that measure for the budget. A single end-of-month reading is an estimate when storage changed throughout the month.

Subtract the allowance before applying the rate

Keep the backup calculation on its own row so the team can see what changes it.

Billable backup GB = max(0, retained backup GB - included backup GB)
Monthly backup estimate = billable backup GB × price per GB-month

This estimate assumes the listed amount stays stored for a full month. For Parcel's example, 18 GB retained with a 10 GB allowance leaves 8 GB billable. At an assumed rate of $0.05 per GB-month, the backup row is $0.40.

The $0.40 estimate uses 18 GB as a planning input. Once Parcel has run through its usual work, replace that input with measured usage. Another app keeping backups for the same number of days can store a different amount.

Keep live storage, database compute, and backup storage on separate rows, and add any transfer or restore fees the provider lists. That way, the team can see what it pays to keep backups and what it pays to use them.

Budget for a restored database too

During a restore drill, Parcel needs a second database long enough to connect a test app and check the recovered orders. Include that database's compute and storage in the estimate using the provider's billing rules.

Choose who will remove that copy and when. A test database left running for a week can matter more than a few extra backup gigabytes. Keep the original database until the team has finished its checks; deleting the only source to save money can remove options during recovery.

Try changing one assumption at a time. If the weekly import doubles the stored backup bytes, recalculate the backup row. If the drill takes three days longer, recalculate the cost of the restored copy. The larger change can help you decide what to measure first.

Check that the cheaper choice still recovers the app

Before cutting retention, work through an error Parcel might find on Friday that began on Monday. Could the remaining copies reach a clean state? If a daily data check would find that error sooner, include the work needed to build and watch that check.

Then run a drill with synthetic orders in an isolated environment. Check an old order, a recent order, and one touched by the largest batch job. Connect the test API and read them through the app. Save a test change too, because a database that accepts reads may still have a connection or permission problem for writes.

Measure from the start of the drill through the first successful test write. Record any missing data and manual work so the team can judge whether the plan fits both its recovery needs and its budget.

Apply the same rows to Forte

Forte shared Postgres is open beta. Daily backups are included and kept for seven days; restores go through support. Shared storage costs $0.50 per provisioned GB-month, with active compute billed separately. Daily backups alone do not meet Parcel's one-hour data-loss goal. Forte database pricing

Dedicated Postgres requires closed-alpha access. The documented medium compute rate is $51 per month, and 10 GB of provisioned storage adds $2. Backup storage is included up to provisioned storage, then costs $0.05 per GB-month. Using Parcel's assumed 18 GB retained, those rows total $53.40 per month before other usage or a test copy. This is a model using documented rates, not a customer invoice. Forte dedicated rates

Dedicated retention ranges from one to 35 days. The usable window has a 12-hour margin at its oldest end. Restores create another database, and dedicated databases run on a single node. Confirm access and beta commitments before relying on the tier for a live app. Forte backups and restore

Use the database guide to check the recovery fit. Then replace each estimate in your worksheet with a dated storage reading or a result from a drill.