Start with the files your application creates
Object storage is a useful shortlist for user uploads, generated reports, and other files that need to outlive a web process. Keep searchable application records and permissions in the database; store each file with an object identifier the application can resolve. This guide covers application files, rather than shared filesystem or database-disk requirements.
Our recommendation is to evaluate the app’s existing cloud first. A separate provider may be justified by a specific requirement, but account for the integration, transfer, and support work. The table compares billing components and access mechanisms, not regional prices or a cheapest-provider ranking.
Keep private files private
For a customer document, the app should check the user’s right to access that specific file before issuing temporary access. A storage URL is not an application permission model. Use the provider’s scoped mechanism in the table and limit the allowed operation and lifetime to the task.
Treat access links as credentials. Avoid putting them in analytics events or broadly visible logs. For uploads, validate file size and type, use unique object identifiers, and decide when a file becomes available to other users. A completed upload is not evidence that the contents are safe or belong to the claimed account.
Compare the access pattern as well as the stored size
Two apps with the same stored capacity can have different bills. One might keep documents that are rarely read; another might serve each uploaded image thousands of times. Record retained data, average object size, upload and download request counts, bytes delivered, and where traffic goes.
Ask for an estimate covering storage, operations, retrieval, and applicable network charges. Include versions, replication, unfinished multipart uploads, and any delivery or image-processing service you select. Check minimum storage durations and early deletion charges before moving frequently replaced files into a colder tier.
Use an online tier for files the application needs immediately. Archive is a separate recovery decision. Confirm the restore process and acceptable delay before using it for files customers expect to download on demand.
Design deletion and recovery together
Set a policy for accidental deletion, overwritten files, customer deletion requests, and account closure. Versioning, retention, replication, and independent recovery copies have different purposes. Check their exact behavior and cost for your selected service before enabling them.
Test recovery of a file alongside the database record that refers to it. Restoring the database alone may leave missing files or permission mismatches. Deleting a record alone may leave chargeable or sensitive objects behind. Include both sides in the operating runbook.
Test portability before choosing another endpoint
OCI documents an Amazon S3 Compatibility API. Compatibility still needs testing against the calls your application makes. Verify uploads, downloads, temporary URLs, metadata, multipart behavior, and error handling; do not assume every provider feature or permission rule transfers unchanged.
For a working architecture that connects uploads to the database and deployment process, continue to the PostgreSQL web-app hosting guide. Read the comparison method for source dates and exclusions.