How to Store PDF Files in a Database: MySQL and Oracle Guide

Storing PDF Files in a Database: The Basic Approach

To store a PDF file in a database, save its binary bytes in a BLOB column. Keep file details in nearby fields, such as its name, type, size, and upload date. Your app can then read the bytes and send them as a PDF response.

This method keeps file data and business data in one place. It can also simplify access rules and backups. The trade-off is clear. Large files can increase database size, backup time, and query load.

For small and mid-sized PDFs, database storage often works well. For files over 90 MB, compare database storage with object or file system storage. Test both choices with real backup and download loads.

• Store PDF bytes in a binary column.
• Store file metadata in normal text and number columns.
• Use a streaming method for large uploads and downloads.
• Keep file access behind your app's sign-in and access checks.

Choose the Right Database and Data Type

Database systems use different names and limits for binary data. MySQL offers BLOB types and VARBINARY. Oracle uses BLOB columns for large binary objects. The right choice depends on file size and how you read the data.

VARBINARY suits short binary values with a known upper limit. A BLOB suits files that may grow larger. In MySQL, TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB have different size limits.

Oracle BLOB columns can hold much larger values than common application limits. Oracle also offers storage settings that affect read speed and space use. Review the MySQL BLOB data type guide before choosing a column.

System	Common type	Best fit
MySQL	BLOB or MEDIUMBLOB	Small to large PDFs
MySQL	LONGBLOB	Very large files, with care
Oracle	BLOB	PDF files of varied sizes

Do not place PDF bytes in a text field. Text fields can change or reject binary bytes. They also add size when you encode a file as Base64.

How to Store a PDF File in a MySQL Database

First, create a table with a binary column and useful metadata. This example uses MEDIUMBLOB, which supports files up to about 16 MB. Use LONGBLOB only when your app needs its larger limit.

CREATE TABLE pdf_files (
 id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
 file_name VARCHAR(255) NOT NULL,
 mime_type VARCHAR(100) NOT NULL,
 file_size INT UNSIGNED NOT NULL,
 pdf_data MEDIUMBLOB NOT NULL,
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Next, read the file as bytes in your server code. Use a prepared statement for the insert. This keeps the file separate from SQL text and blocks many injection risks.

INSERT INTO pdf_files
 (file_name, mime_type, file_size, pdf_data)
VALUES (?, ?, ?, ?);

Bind the first three values as text or numbers. Bind the fourth value as binary data. Many drivers offer a stream bind method. Use it when files may be large.

Check the MySQL server and driver limits before testing. The max_allowed_packet setting can block a large insert. Web server limits can block the upload before MySQL sees it.

Store a hash, such as SHA-256, when you need change checks. The hash helps detect damaged or replaced files. It does not replace access control.

How to Store a PDF File in an Oracle Database

Oracle uses the BLOB type for PDF bytes. Create a table with a BLOB column and fields for file details. Keep the table key simple, then add indexes for fields used in searches.

CREATE TABLE pdf_files (
 id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 file_name VARCHAR2(255) NOT NULL,
 mime_type VARCHAR2(100) NOT NULL,
 file_size NUMBER NOT NULL,
 pdf_data BLOB NOT NULL,
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

In an Oracle app, bind the PDF as a binary stream. A common insert uses a bind variable for the BLOB value. The driver then sends the file bytes without turning them into text.

INSERT INTO pdf_files
 (file_name, mime_type, file_size, pdf_data)
VALUES (:name, :type, :size, :data);

Some Oracle tools use a temporary LOB for large writes. The app creates the temporary value, writes the stream, and sends it in the insert. Close and free temporary LOBs after the write.

Oracle storage settings can change the cost of large reads. The Oracle LOB overview explains key BLOB storage choices. Test secure file settings with your own backup and read pattern.

Database Storage or the File System?

Database storage gives your app one control point. A row can hold the PDF, owner, status, and access rules. One backup process can protect both the file and its metadata.

This design also supports database transactions. The app can save a record and its PDF in one unit. That helps prevent records that point to missing files.

Still, database storage has costs. A table with millions of large PDFs can slow backups and raise storage bills. Large binary reads can also compete with normal business queries.

File system storage keeps bytes outside the main database. Store a safe file key or path in the table. Do not trust a user-supplied path. Generate names and keep the storage folder outside the public web folder.

• Choose database storage for strict row-level access and simple backups.
• Choose file system or object storage for huge files and high download volume.
• Use a hybrid plan when metadata needs database searches.
• Back up both the table and file store in a tested plan.

Retrieve and Display PDF Files

Retrieval starts with a small query for one file. Fetch the PDF bytes by its ID after checking the user's rights. Do not let a public URL expose a raw database row.

SELECT file_name, mime_type, file_size, pdf_data
FROM pdf_files
WHERE id = ?;

Your server should send the correct content type. For PDFs, that value is application/pdf. Set a safe download name with the Content-Disposition header.

Use inline display when the browser should open the PDF. Use attachment when the user should save it. A download endpoint can stream the BLOB instead of loading all bytes into memory.

For previews, return a short-lived access link or a rendered page. Do not convert every PDF during each request. Cache previews when the same file gets many views.

Best Practices for PDF File Storage

Set file size limits before the upload begins. A 20 MB limit may suit one site, while another needs 200 MB. Reject files that exceed the limit with a clear error.

Check the file type in more than one way. Inspect the declared type and the file signature. A name ending in .pdf does not prove that the content is a PDF.

Use access checks on every read. Encrypt database disks and backup copies when the files hold private data. Limit database accounts to the actions that the app needs.

Plan backups around file size, restore time, and growth. A backup that runs for six hours may not meet your recovery goal. Test a full restore, then open several restored PDFs.

Track file size and query time. Watch database growth, backup duration, failed uploads, and download errors. These numbers show when a file store should replace database storage.

1. Set a clear file size and type policy.
2. Use prepared statements and binary stream binds.
3. Index metadata, not the PDF bytes.
4. Stream large reads and writes.
5. Test backup and restore with large files.
6. Review database growth each month.

A Practical Choice for Your Project

There is no single answer to how to store a PDF file in a database. Small files with strict access rules often fit well in MySQL or Oracle. Large files with heavy download traffic may fit better in a file system or object store.

Start with a small test. Upload files at 1 MB, 20 MB, 90 MB, and 200 MB. Measure insert time, read time, backup time, and restore time.

Then choose the design that meets your access, cost, and recovery needs. Keep file metadata in the database either way. That choice makes search, ownership checks, and file tracking much easier.