Quick Summary: Stop bloating your database with binary files; here is a battle-tested architecture guide for hosting media-heavy CRM platforms using object storage, CDNs, and sane database practices.

Where Would You Host a Media CRM Platform? (Please Don’t Say the Database)

I was browsing Reddit the other day and stumbled across a thread that triggered a very specific PTSD flashback for me. The user asked simply: “Where would you host a media CRM platform?”

I physically winced. Years ago, I inherited a “CRM” from a developer who shall remain nameless. This platform was designed for insurance adjusters to upload accident photos. Instead of using file storage, this developer decided to store high-res JPEGs directly into a MySQL LONGBLOB column on prod-db-01.

It worked fine for the first 50 users. But three months later, I woke up at 3:00 AM because our backups were taking 26 hours to complete, locking the tables, and timing out the web app. The database was 400GB, and 399GB of that was photos of dented bumpers. Don’t be that developer.

The “Why”: Unstructured vs. Structured Data

The root cause of most media hosting disasters is a misunderstanding of what databases are for. Your Postgres or SQL Server instance is optimized for relationships, indexing, and rapid text retrieval. It runs on expensive, high-IOPS storage.

Media files (images, PDFs, videos) are unstructured data. They don’t need relational integrity; they just need a place to sit until someone asks for them. If you mix the two, you kill your database performance and make horizontal scaling impossible because your application state is tied to the local disk of a single server.

Here are the three ways I handle this architecture at TechResolve, ranging from “I need this up tonight” to “We are scaling to millions of users.”

Solution 1: The Quick Fix (The Monolith with Block Storage)

If you are building an MVP or an internal tool with limited users, you don’t need a complex cloud architecture yet. You can stick to a classic VPS (like a DigitalOcean Droplet or EC2 instance), but do not store the files on the root volume.

The Strategy: Mount a separate, resizeable Block Storage volume to your OS. Configure your web server (Nginx/Apache) to serve static files from that mount point.

Pro Tip: By separating the OS disk from the data disk, you can resize the storage volume independently without downtime. If your storage fills up, you just click “Resize” in the console and expand the file system.

Here is what the docker-compose.yml looks like when we do this for internal tools:

version: '3.8'
services:
  app:
    image: my-crm-app:latest
    volumes:
      # Mount the block storage volume to the container
      - /mnt/volume_nyc1_01/media_uploads:/var/www/html/public/uploads
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      # Nginx serves the files directly, bypassing the app logic for speed
      - /mnt/volume_nyc1_01/media_uploads:/var/www/html/public/uploads

Verdict: It’s cheap and simple, but it’s a “Pet” server. If the server dies, you better hope your volume snapshots are up to date.

Solution 2: The Permanent Fix (Object Storage + CDN)

This is the industry standard. If you are charging money for this CRM, this is what you should be building. We decouple the storage completely from the compute resources.

The Strategy:

• App Server: Handles logic only. Ephemeral. Can be destroyed and recreated at will.
• Database: Stores metadata only (file path, file size, upload date).
• Object Storage (S3/R2/Wasabi): Stores the actual binary files.
• CDN (CloudFront/Cloudflare): Caches the content closer to the user.

When a user uploads a file, your backend generates a Presigned URL. The browser uploads the file directly to S3, bypassing your weak application server entirely. This saves your bandwidth and prevents your Node/Python server from choking on large uploads.

Here is a comparison of costs I ran for a client recently:

Solution 3: The ‘Nuclear’ Option (Managed DAM)

Sometimes, the client has more budget than patience, or the media requirements are insane (e.g., “We need to resize 4K raw footage into 12 different formats on the fly”).

The Strategy: Use a dedicated API like Cloudinary or Imgix. You treat media entirely as a third-party service.

In this scenario, your code literally just stores a string URL in the database. You offload storage, optimization, CDN delivery, and transformation to them. It is expensive—eye-wateringly expensive at scale—but it saves me from having to write an ImageMagick microservice that leaks memory every Tuesday.

My advice? Start with Solution 2 (S3 + CDN). It keeps your options open, keeps your database clean, and won’t wake you up at 3:00 AM.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions