Designing a Hosted Media Upload Path That Does Not Burden the Database

Designing a hosted media upload path that does not burden the database

Images and videos are application data, but their bytes rarely belong in the application’s primary relational tables. Large binary values expand backups, replication and query work while making ordinary content operations slower.

A cleaner model stores objects in an object service and keeps only governed metadata and relationships in the database.

Authorise the intent first

The application begins an upload by authenticating the user and checking organisation, project, plan and content rules. It creates an upload intent containing a generated object identity, allowed size, accepted media class, expiry and eventual record relationship.

The browser receives short-lived permission for that one intent. It does not receive a reusable storage account key or permission to list a tenant container. This is the valet-key pattern: delegate one narrow operation for a short period.

Treat the uploaded object as untrusted

Client-declared filename and content type are hints. Validate size and object identity after upload, inspect file signatures where appropriate, strip unsafe metadata when the product contract allows it and run malware scanning before public delivery.

Keep the object quarantined while checks are pending. “Upload succeeded” and “asset is safe to publish” are different states.

Store metadata, not bytes

The database record can hold:

• tenant and project ownership;
• stable asset identifier;
• provider-neutral object key;
• media type, size and checksum;
• scan and moderation state;
• uploader and timestamps;
• references from content records; and
• lifecycle or deletion state.

Avoid storing provider credentials or expiring signed URLs. Generate delivery authorization when needed.

Make replacement and deletion explicit

Replacing an image should create or select a new object, verify it, update the content reference and retire the old object after the safe window. Overwriting bytes under one key weakens caching and auditability.

Deletion is a workflow: remove public reachability, mark references, delete or expire the object, clean derivatives and retain only required audit evidence. Periodic reconciliation should find abandoned upload intents and unreferenced objects.

Serve for the audience

Public marketing assets may use cacheable public delivery after approval. Private customer documents need authenticated or short-lived access. Range requests matter for video and large media. Derivatives should inherit the source asset’s tenant and publication rules.

BlinkHost Hosted Object Storage applies this separation to hosted applications: scoped upload intent, object bytes in Azure-backed storage, managed metadata, tenant boundaries and metered usage. It avoids creating an ad hoc storage account for every application while preserving per-organisation isolation and billing controls.

Primary references

• Azure Architecture Center: valet key pattern
• Azure Blob Storage upload guidance
• OWASP File Upload Cheat Sheet
• IETF HTTP range requests

Reviewed 2 September 2026. Exact limits and scanning availability depend on the active product plan and documented service lifecycle.