Vercel Blob vs Netlify Blobs

Vercel Blob and Netlify Blobs both store unstructured data, such as files, images, and JSON, without requiring you to run your own storage infrastructure. Each automatically provisions, handles access control for you, and exposes an SDK you call from server-side code. The main difference is the storage model: what you put in, how you read it back, and how it reaches your users.

Vercel Blob is object storage built into the Vercel platform. You upload a file with put() and get back a URL. Public blobs are served directly from that URL through Vercel's CDN, and private blobs are streamed through your Vercel Functions after an authentication check. It runs on Amazon S3, supports files up to 5 TB, and is built to serve media and user uploads at scale.

Netlify Blobs is a key/value data store for Netlify sites. You open a store with getStore(), then read and write entries by key with get() and set(). There are no public blob URLs, so every read happens inside your Netlify Functions, Netlify Edge Functions, or build plugins. It offers a configurable consistency model and arbitrary per-object metadata, making it suitable for use as a key-addressed data store or a basic database rather than a public file host.

The right choice usually comes down to whether you need public, CDN-served file URLs or a key-addressed store behind your own code, where you host, and how you want the data billed. This guide compares the two across model, API, delivery, limits, and pricing, then closes with a scenario-by-scenario guide so you can match each one to what you're building.

Both services store unstructured data and manage the underlying infrastructure for you. The differences lie in the access model, how data reaches users, and the limits and pricing associated with each.

Vercel Blob is object storage. You address each blob by a pathname like avatars/user-123.png and get a URL back when you upload. The store is either public or private, and you set that mode when you create it. Public blobs are fetched straight from their URL, so they work as src and href values in your HTML. Private blobs have a non-public URL that only resolves when you fetch it with get() from your own code, which lets you run an auth check before streaming the file.

Netlify Blobs is a key/value store. You address each entry by a string key inside a named store (a namespace), and you read and write values with get() and set(). Values can be strings, ArrayBuffers, Blobs, or JSON, and each entry can carry up to 2 KB of arbitrary metadata. Netlify Blobs has no blob URLs. To expose data to a browser, you write a function that reads the entry by key and returns it, which keeps every read behind your own code.

In practice, reach for Vercel Blob when the file itself needs a URL, such as an image on a page, a video, or a downloadable document. Reach for Netlify Blobs when you want a key-addressed store that your functions read from, such as cached computation output, form submissions, or per-user JSON.

Both services are tied to a platform account, but can be accessed from other environments using a token. Vercel Blob works with any frontend framework through @vercel/blob, while Netlify Blobs is called from Netlify's own runtimes.

The two SDKs model the same task in different ways. Vercel Blob uploads a file and returns a URL you store or render, while Netlify Blobs writes a value under a key you choose and reads it back by that key.

With Vercel Blob, this is how you upload to a public store and use the returned URL:

import { put } from '@vercel/blob';

export async function POST(request: Request) {
  const form = await request.formData();
  const file = form.get('file') as File;

  const blob = await put(file.name, file, {
    access: 'public',
    addRandomSuffix: true,
  });

  // blob.url is a public CDN URL you can render or link to directly
  return Response.json({ url: blob.url });
}

With Netlify Blobs, write a value under a key and read it back from inside a function:

import { getStore } from '@netlify/blobs';

export default async (req: Request) => {
  const uploads = getStore('file-uploads');
  const form = await req.formData();
  const file = form.get('file') as File;

  const key = crypto.randomUUID();
  await uploads.set(key, file, {
    metadata: { uploadedAt: Date.now() },
  });

  // Read it back by key; there is no public URL
  const entry = await uploads.get(key);
  return new Response(entry);
};

Vercel Blob hands you a URL the browser can request directly, while Netlify Blobs stores the bytes under a key that only your code can resolve.

Vercel Blob's strengths come from being object storage built for the web: public URLs, CDN delivery, large-file handling, and direct browser uploads.

Public blobs are served directly from a *.public.blob.vercel-storage.com URL through Vercel's CDN, so you can drop a blob URL straight into an <img> tag or a download link. All blobs, public and private, are cached for up to one month by default, and you control that with the cacheControlMaxAge option.

Public downloads are billed primarily as Blob Data Transfer, which is, on average, 3x more cost-efficient than Fast Data Transfer thanks to its volume-optimized delivery. Each access of a blob URL also counts as a standard CDN Edge Request, and cache misses add Fast Origin Transfer. Blobs above the 512 MB cache limit are always served from the origin, so they incur both on every request. Netlify Blobs has no public URL, so serving a file to a browser always requires a function to read the entry and return it.

Each blob can be up to 5 TB. For files larger than 100 MB, the SDK's multipart support splits the upload into parts, uploads them in parallel, and retries only the parts that fail. This makes large media and backups practical. Netlify Blobs caps an individual object at 5 GB, enough for data records and cached payloads but not large video files.

With client uploads, the browser sends the file directly to the store rather than routing it through your server. So you avoid your function's body size limits and pay no data transfer costs for the upload. Your server's only job is a short handler that authorizes the upload and signs a token. Netlify Blobs has no built-in browser upload path, so you accept the file in a function and call set() yourself, which means the file passes through your function first.

You choose an access mode when you create a store. Public stores serve files to anyone with the URL, and private stores require authentication for every read and write, with delivery streamed through your Vercel Functions. When your code runs on Vercel, the SDK authenticates to the store with OIDC by default for both public and private stores, so credentials rotate automatically rather than relying on a long-lived token. This gives you one product for both public assets and sensitive documents.

Vercel Blob runs on Amazon S3, with 99.999999999% (11 nines) durability and 99.99% availability in a given year. Storage and operation pricing match S3 directly: $0.023 per GB-month of storage, $0.40 per million simple operations, and $5.00 per million advanced operations, with Blob Data Transfer starting at around $0.05 per GB, depending on the region. The Hobby plan includes 1 GB of storage and 10 GB of Blob Data Transfer per month at no cost. Your bill shows storage, operations, and transfer as separate line items.

Netlify Blobs' strengths come from being a zero-configuration key/value store: a database-like API, tunable consistency, and deploy-scoped data.

Netlify Blobs reads and writes by key, allowing it to act like a basic database without you having to provision one. You can store strings, binary data, or JSON with setJSON(), attach up to 2 KB of arbitrary metadata per object, and read just the metadata with getMetadata() to check whether an entry exists without downloading it. You can also group keys hierarchically with / and list them as directories. Netlify encrypts blobs at rest and in transit, so you can keep sensitive data in a store as long as your access code treats user input as unsafe. Vercel Blob exposes system fields like content type and ETag, but not arbitrary key/value metadata.

You choose between eventual and strong consistency, either for a whole store or for a single read. Eventual consistency keeps reads fast and propagates updates within 60 seconds, while strong consistency guarantees the latest write but slows reads. This per-operation control helps when some reads can tolerate staleness and others can't. Vercel Blob doesn't expose a consistency setting, meaning reads are served from cache and changes propagate within 60 seconds.

set() and setJSON() accept onlyIfNew to write only when a key doesn't exist, and onlyIfMatch to write only when the stored ETag matches, which guards against overwriting concurrent changes. Netlify has no built-in locking, so the last write wins; these options are how you build safe updates. Vercel Blob offers comparable conditional writes through the ifMatch option on put(), copy(), and del().

With getDeployStore(), a store is scoped to a specific deploy and managed like any other deploy asset. It stays in sync through rollbacks and is cleaned up automatically when the deploy is deleted, so a preview deploy can't clobber production data. Build plugins and file-based uploads that write to these deploy-specific stores. Vercel Blob stores are independent resources that you connect to projects rather than tie to a single deployment.

You can ship blobs with a deploy by placing files under .netlify/blobs/deploy in your repository, with optional JSON sidecar files for metadata. Netlify uploads them to a deploy-specific store during deployment, allowing framework authors to seed data without writing a build plugin. Vercel Blob uploads occur at runtime or via the CLI, rather than as part of the deploy artifact.

Netlify Blobs is available on all plans and provisions with zero configuration, so there's no separate storage product to enable. Usage draws from your team's monthly credit allotment, which is 300 credits on the Free plan, 1,000 on Personal, and 3,000 on Pro, through Netlify's standard bandwidth and request metering. Netlify doesn't publish a separate per-GB storage rate for Blobs the way object-storage services do, so for teams already on Netlify, there's no extra storage service to set up or bill.

The right tool depends on whether you need public file URLs or a key-addressed store, where you host the data, and how the data should be billed.

The decision comes down to model and platform.

Teams building on Vercel that need to store and serve files, especially public media or large user uploads with direct URLs and CDN delivery, get the tightest fit with Vercel Blob and its S3-backed durability.

Teams building on Netlify that want a zero-configuration key/value store for data behind their own functions, with tunable consistency and deploy-scoped data, will find Netlify Blobs a natural fit.

Files SDK is a third-party library that provides a single-file storage API with pluggable adapters, including support for both Vercel Blob and Netlify Blobs. If you want to write your storage code once while keeping the option to switch providers, you can target the SDK's interface and let an adapter handle communication with each backend. That also turns a move between the two into a configuration change rather than a rewrite.

Each adapter ships as part of files-sdk, with the matching blob package (@vercel/blob or @netlify/blobs) as an optional peer dependency you install alongside it. You construct the SDK with the adapter you want:

import { Files } from 'files-sdk';
import { vercelBlob } from 'files-sdk/vercel-blob';

// On Vercel, the adapter uses OIDC when the Blob store is connected to your
// project, and falls back to BLOB_READ_WRITE_TOKEN otherwise.
const files = new Files({ adapter: vercelBlob() });

import { Files } from 'files-sdk';
import { netlifyBlobs } from 'files-sdk/netlify-blobs';

// On Netlify runtimes, the site ID and token are auto-detected from the
// function context. Pass them explicitly when running outside Netlify.
const files = new Files({
  adapter: netlifyBlobs({
    name: 'uploads',
    // deployScoped: true,     // use getDeployStore()
    // consistency: 'strong',  // or 'eventual' (default)
  }),
});

Because the SDK normalizes both backends to one StoredFile shape, the adapters expose the same methods, but a few capabilities reflect the underlying product differences.

Public URLs work through the Vercel Blob adapter, not the Netlify one. With public access, url() on the Vercel Blob adapter returns the permanent CDN URL, with no expiry or signing. The Netlify Blobs adapter has no url() support because Netlify Blobs has no public URL, so you call download() or proxy the bytes through your app. With Vercel's private access, url() is also unavailable, since private blobs are read through an authenticated get().

Server-side operations differ as well. The Vercel Blob adapter copies directly, while the Netlify Blobs adapter implements copy() by fetching and re-uploading the source, which isn't server-side atomic. Streaming uploads buffer in memory on Netlify, because its set() has no streaming form, and resumable uploads aren't available. The Vercel Blob adapter lists no such caveat on upload.

Metadata runs the other way. The Netlify Blobs adapter packs size, content type, last-modified, cacheControl, and your own metadata into Netlify's metadata map, so the unified shape round-trips. The Vercel Blob adapter supports cacheControl, which maps to cacheControlMaxAge, but rejects user metadata because the Vercel Blob API has no field for it.

• Get started with Vercel Blob using the server upload or client upload quickstarts, or read the Vercel Blob overview for how stores, access modes, and delivery work.
• Explore the full API in the @vercel/blob SDK reference, and review private storage for serving authenticated files.
• Compare usage and costs in the Vercel Blob pricing docs.
• For the Netlify side, see the Netlify Blobs documentation for the store API, consistency model, and limits.