Storage: Blob, Edge Config, And Databases
Deployment platforms serve code, but real applications also need places to store data. A contact form may need a database record. A profile page may need uploaded avatars. A feature flag may need low-latency configuration. A product catalog may need structured records. Vercel offers and integrates with several storage options, including Vercel Blob, Edge Config, Postgres, and marketplace providers.
The beginner mistake is treating the Git repository or deployment filesystem as storage. A repo is for source code and durable project files. It is not a place for user uploads, private customer data, changing application state, generated invoices, or database backups. Deployments are built artifacts, not a writable production hard drive you should depend on.
Choose Storage By Data Shape
Different data needs different storage. Do not choose a tool only because it appears in the dashboard. Start with the data shape and access pattern.
Ask these questions:
Is the data a file or a structured record?
Is it public or private?
Does it change often?
Does it need transactions?
Does it need fast global reads?
Does it need search or relational queries?
Who can upload it?
Who can delete it?
How long must it be retained?
A profile photo, a feature flag, and an order record should not automatically use the same storage service.
Vercel Blob
Vercel Blob is designed for file-like objects such as images, PDFs, exports, attachments, and user uploads. It is a better fit for uploaded files than committing files to Git or trying to write into the deployment output.
A typical upload flow is:
User selects file.
App validates file type and size.
Server creates or authorizes the upload.
File is stored in Blob.
Database stores metadata and ownership.
App serves or links the file according to access rules.
Do not skip validation. File uploads can be abused. Check size, type, extension, ownership, and intended visibility. If a file is private, design private access deliberately instead of assuming an obscure URL is enough.
Blob stores files, but your application still needs to know what those files mean. A database record may store the user id, original filename, content type, file size, storage URL or key, creation time, and deletion status.
Edge Config
Edge Config is for low-latency configuration data that can be read near the edge. It is useful for feature flags, simple routing decisions, allowlists, experiment settings, maintenance banners, and other small configuration values that need fast reads.
Edge Config is not a general database. It is not where you store every user record, every order, or arbitrary large documents. Its strength is fast configuration access, not complex relational querying or high-volume writes.
Good Edge Config candidates include:
feature flags
country allowlists
maintenance mode flags
small routing maps
experiment variants
read-heavy configuration
If the data is user-generated, relational, transactional, or needs rich querying, use a database instead.
Databases
Databases store structured application data. User accounts, orders, posts, comments, invoices, subscriptions, products, and permissions usually belong in a database. Vercel can integrate with database providers, and the Vercel marketplace can help connect services to projects.
A database brings responsibilities. You need schema design, migrations, backups, indexes, access control, environment separation, and safe connection handling. A database URL is a secret and belongs in Environment Variables, not in frontend code or committed files.
For Preview Deployments, decide whether previews use a staging database, a branch database, seeded test data, or production read-only access. Do not casually point preview code at production data. A preview form can still write to a real database if configured that way.
Marketplace Providers
The Vercel Marketplace can connect projects to storage, database, observability, and other providers. Integrations can simplify setup, environment variables, and team workflows. They do not remove the need to understand the service you are adding.
Before installing a provider, review its pricing, region options, backups, access controls, data retention, export path, and support expectations. For client work, confirm who owns the provider account and billing. A database created under the wrong personal account can become a painful handoff problem later.
Do Not Use The Repo For Uploads
A Git repository is not upload storage. User uploads should not become commits. Uploaded files should not be written into public/ as a production workflow. Database exports, private documents, certificates, and customer files should not be kept in source control.
Using the repo for uploads creates several problems. Deployments may not persist changes. The repo grows with binary files. Secrets or private files can leak. Rollbacks become confusing. Build times increase. Access control becomes impossible to reason about.
Use object storage for files, a database for structured records, and source control for source code.
Public vs Private Files
Storage design must include visibility. Some files are meant to be public: product images, public downloads, favicons, and marketing assets. Other files are private: customer invoices, identity documents, internal exports, signed contracts, and private user uploads.
Public files can be cached and linked openly. Private files need authorization checks, short-lived access URLs, signed requests, or server-side streaming depending on the service and app. Do not make private files public because it is easier for the frontend.
The access model should be part of the data model. A file should have an owner, visibility, allowed actions, and retention rules.
Environment Separation
Storage resources should usually differ across Local, Preview, and Production. Local development can use local emulators, test accounts, or development resources. Preview can use staging resources. Production should use production resources with stricter access.
Keep variable names stable and values scoped by environment. For example, use the same BLOB_READ_WRITE_TOKEN name with different values rather than adding environment-specific branches in application code.
When copying production data to staging, remove private information unless there is a clear approved process. Staging leaks are still leaks.
Cost And Retention
Storage has cost. Files consume space and bandwidth. Databases consume storage, compute, backups, and sometimes connection capacity. Edge configuration may have limits and pricing. Marketplace providers have their own billing models.
For commercial projects, decide who pays, who monitors usage, how long files are kept, how deleted users are handled, and how data can be exported. Cost control and data retention should be designed before launch, not after the first surprise bill or privacy request.
Upload Lifecycle
An upload is not finished when the file reaches storage. The application should know who uploaded it, why it exists, whether it is still referenced, and when it should be deleted. Without that lifecycle, storage slowly fills with abandoned files that nobody wants to remove because nobody knows whether they are safe to delete.
For user uploads, store metadata in a database. Record the owner, purpose, storage key, size, content type, visibility, creation time, and deletion state. If a user replaces an avatar, decide whether the old image should be deleted immediately, retained briefly for rollback, or kept for audit reasons. If a draft upload is never attached to a published record, decide when cleanup removes it.
This lifecycle matters for privacy too. When a user deletes an account or a client asks for data removal, the app needs to know which stored files belong to that person or project. A bucket full of anonymous filenames is hard to audit.
Migrations, Backups, And Recovery
Databases and storage need recovery plans. A production database should have a backup story before it holds important data. A file storage system should have a deletion policy and, when needed, a recovery policy. Edge configuration should have a way to review changes and restore a known-good value if a bad flag breaks the app.
Migrations deserve the same caution as deployments. A schema migration can break a function even when the frontend build succeeds. A storage migration can move files while old URLs still exist. A configuration change can disable a feature for every user instantly. Test migrations in Preview or staging environments before production when possible.
For client projects, write down who can restore data and how long restoration might take. Backups are not useful if nobody knows where they are, who can access them, or whether they have ever been tested.
Local Development Habits
Local development should not casually use production storage. A developer testing uploads should use a local fixture, a development bucket, or a staging resource. A developer testing database writes should not accidentally create real customer records. Environment separation protects production from mistakes made during ordinary development.
Seed data helps. Instead of copying production records into local development, create fake records that cover the same shapes: a user with no uploads, a user with many uploads, a missing file, a private file, and a deleted file. Good fixtures let you test edge cases without exposing private data.
Common Mistakes
The first mistake is using the repository as upload storage.
The second mistake is putting private files in public/.
The third mistake is using Edge Config like a general database.
The fourth mistake is exposing database URLs to frontend JavaScript.
The fifth mistake is pointing Preview Deployments at production writable data without review.
The sixth mistake is installing marketplace providers without deciding ownership and billing.
Review Questions
- When is Blob a better fit than a database?
- What kind of data fits Edge Config?
- Why is a Git repository not upload storage?
- What should a database environment variable protect?
- Why should Preview and Production storage be separated?
- What storage questions matter for commercial projects?