When building Elevan — a learning tool — I faced an interesting challenge. Our app needed to support file uploads up to 50MB, but once I deployed it to Vercel, uploads larger than 4.5MB failed. The problem? Vercel's serverless functions come with a hard limit of 4.5MB for request body size. While everything worked perfectly in my local environment, users in production were blocked from uploading larger files.

If you've never heard of serverless functions, don't worry — here's a quick explanation.

What Are Serverless Functions?

Vercel's serverless functions are lightweight pieces of code that run only when needed, like when handling API requests. They're fast, scalable, and cost-efficient since they only run for the duration of a task. However, because they're meant to stay fast and lightweight, they have limitations — like the 4.5MB body size limit.

This limitation isn't random. Serverless functions are designed to be lightweight and responsive, acting as an API layer rather than a full-fledged media server. Instead of transferring large media files through serverless functions, Vercel encourages developers to send metadata and handle media elsewhere. While Vercel offers its own Blob Storage, we use Supabase as our backend, so I needed a solution that works seamlessly with Supabase's Blob Storage.

Let me show you how I solved the challenge by changing the approach.

The Challenge

In our initial setup, the workflow looked like this:

Users Uploaded Files: Files were uploaded to our server using a Next.js API route.
Server Processed Files: The server (FastAPI) extracted text or performed other operations on the files.
Files Saved to Supabase: The processed files were then stored in Supabase Blob Storage.

This worked well during local development. But in production, it failed when users tried uploading files larger than 4.5MB. The issue? Vercel's serverless functions (used in the Next.js API routes) have a hard limit of 4.5MB for request body size, making this setup unsuitable for handling large files.

The Solution

To overcome this limitation, I reworked the system. Instead of uploading files through the serverless function, users now upload them directly to Supabase Blob Storage. The serverless function (Next.js API route) only handles metadata (like the file URL and size), which it sends to the FastAPI server for further processing.

New Workflow

Here's how it works now:

1. File Uploads Go Directly to Supabase:

Users upload their files directly to Supabase Blob Storage using the browser.
This bypasses the serverless function entirely, avoiding the 4.5MB size limit.

2. Send Metadata to FastAPI Server:

After the file is uploaded, the browser sends a small piece of metadata (e.g., file URL, name, size) to a Next.js API route.
The Next.js API route forwards this metadata to the FastAPI server for processing.

3. Server Processes the File:

The FastAPI server retrieves the file from Supabase Blob Storage using the provided URL.
It processes the file (e.g., extracts text, partitions it, etc.) and saves the results.

Why This Works

No More Size Limit Issues: Large files never touch the serverless function, so the 4.5MB restriction is no longer a problem.
Efficient Architecture: The file upload process is offloaded to Supabase, while the server only processes metadata and downloads files as needed.
Scalability: Supabase Blob Storage can handle files up to 5GB, ensuring room for future growth.

Takeaway

If you're running into file size limits on Vercel (or any other serverless platform), offloading large file uploads to a dedicated storage solution like Supabase Blob Storage is a great option. It keeps your serverless functions lightweight, fast, and free from bottlenecks.

If you want to learn how to process files of all types (PDFs, MP3s, MP4s, and more), check out this blog: Turn Anything Into LLM-Ready Data.

I hope this helps you in your projects! Let me know if you have any questions.