The team building Relay Clinic, a hypothetical referral app for several clinics, is choosing a managed Postgres plan before its first pilot with patient data. Both plans on its shortlist include encryption and backups, and one has a lower base price. Before the team can compare what it would pay, it needs to find out whether either plan meets the app's contract, access, recovery, and availability requirements.
Write down what would make the team hold the decision, then try the proposed tier with the app's code and fake records. When you rehearse a restore, follow the process until a staff member can use the recovered app. That will show you which steps the team needs to run after the provider finishes its part.
Set requirements for one referral app
Relay Clinic stores referral notes and restricts each clinic's staff to their own referrals. To size the database for the pilot, estimate how much data it will keep, how quickly it will grow, which queries will run most often, and how many connections the app will open. Use those estimates to compare plans at the load the team expects during the pilot.
Ask the clinics how much recent work they could lose and how long they could wait to read and save referrals again. The first limit is the recovery point objective, and the second is the recovery time objective. For this example, suppose the clinics can tolerate losing up to fifteen minutes of writes and can wait up to two hours for the app to return. Agree on limits for your own app before you check what a provider can deliver.
Review the exact service and agreement
Bring the product, tier, account, region, and the paths for backups and support to your privacy and legal reviewers. Have them check the signed or applicable Business Associate Agreement for that exact setup before you send patient data.
Keep both the database and backup copies in the review. A cloud provider can have business associate duties even if it holds encrypted electronic protected health information without the key. HHS cloud guidance
Record open questions with owners. If the agreement covers one tier while the team plans to buy another, hold the decision until that gap is resolved. Continue testing with fake rows while the review runs.
Give the database findings to the team doing the wider privacy and security review, where they can assess the app code, operating practices, staff access, and other places the data goes.
Check access from the app and from admin tools
Connect Relay Clinic using the secure settings the provider requires and give the app a database role with the permissions it needs. If the service supports separate roles, use a different role to change tables or run migrations so the app's everyday connection has narrower access.
Sign in as Clinic A and read an allowed fake referral through the API, then request a Clinic B referral by its ID. The server should deny the second request. Check the same rule for lists, search, updates, and exports.
Have the database return only the permitted clinic's rows, and use a page limit and an index that supports the filter. Loading every clinic's referrals puts more data in the app's response path and takes more work as the database grows.
Then check which people can open the database console, export rows, change roles, or request a restore. Have a backup operator run the approved recovery steps under their own login. Record which actions the service audits and which ones the team needs to track.
Test recovery through the app
A daily backup may leave hours of new referrals outside the most recent copy. Point-in-time recovery uses a recorded history of changes so the team can choose a restore point within the window the tier supports. Check how far back that window goes for the plan you're considering.
Keep the test running after the provider reports that the restore finished. With Amazon RDS, for example, a point-in-time restore creates a new database instance, so the team still needs to connect the test app to it and check that referrals work. Amazon RDS point-in-time restore guide
A useful drill follows this order:
- Save fake referrals with known times and clinic IDs.
- Choose a safe recovery point and follow the supported restore process.
- Connect a test copy of the app to the restored database.
- Read the expected referrals, save a new note, and test denied clinic access.
- List the later writes that are missing and explain how a switch would handle them.
Time the full drill, including approvals, support requests, connection changes, and checks. Save the size of the test database and the starting point with the result, since the steps or timing could change for a larger database or a live incident.
Before directing live traffic to the restored copy, decide how you will pause new writes or account for them during the switch. If both copies accept referrals, the team can end up with records split between them.
Check downtime and exit as their own gates
Ask how maintenance, resizing, and a failed database node would affect the app. If a plan gives the database a dedicated server, check whether it also includes a standby and how it would switch over after a failure. Use the plan's written terms to verify any availability commitments.
Test how the app behaves when a database connection fails. It should report failure without claiming a note was saved. Check that a retry cannot create a second referral and that error output keeps the note text out of general logs.
Also test an export with fake rows. Open the export in another suitable environment, check the schema and row counts, and read the records through a test app. Record the work needed to move extensions, roles, and settings. An export format is useful only if the team can use it when leaving the service.
Compare costs once a plan passes the checks your app depends on. Price the same workload on each plan, including backups, retained changes, storage growth, support, and the temporary cost of keeping a restored copy.
Apply the checks to Forte's proposed tier
Forte managed databases are in Open Beta. Shared Postgres keeps daily backups for seven days, and the team requests a restore through support. Shared Postgres has no high availability. Relay Clinic would need a way to restore more recent writes to meet its hypothetical fifteen-minute data-loss target.
Dedicated Postgres is in Closed Alpha and requires approval for access. It adds point-in-time restore on a single node. Review the tier's maturity and limits, then check what the written terms commit to for this workload, including availability and recovery time. Forte database docs
Discuss patient-data use and BAA scope through Forte support. Name database storage, backups, logs, administrator access, and support. Then run the proposed tier through the same synthetic access and restore checks used for other options.
If you want to discuss that fit, use the form below with estimated size, access rules, acceptable data loss, and downtime limits. Keep patient details and connection strings out of the request.