Vercel Storage is now two packages and a pair of deprecations

Two packages remain, and the rest of the shelf was withdrawn

The repository is a monorepo, described in its own package manifest as the monorepo for everything Storage at Vercel, and the README is now mostly a statement of what survives and what does not. Two packages are listed as current. @vercel/global-config is described as ultra-low latency data reads, and @vercel/blob as fast object storage, each with a documentation link and a source path into the packages/ directory. Everything else is under a heading of deprecated packages, and the statement is blunt: @vercel/postgres and @vercel/kv have been deprecated, and the associated products Vercel Postgres and Vercel KV no longer exist. That is a different situation from a package being marked for removal, because the product behind the package is gone. The README also notes that you can install other postgres and KV storage solutions from the Vercel Marketplace as native integrations to your Vercel project, which is the mechanism Vercel is pointing people at instead of its own first-party database services, and that the source code for the deprecated packages is preserved on a separate vercel-kv-vercel-postgres-archive branch.

The migration targets are named, and the Postgres path has conditions

The migration section is the most useful part of the README for anyone who still has the old packages in a dependency tree. For @vercel/postgres the guidance is to use @neondatabase/serverless or @neondatabase/vercel-postgres-compat, the latter described as a drop-in replacement, with a pointer to the Neon transition guide and specifically to its compatibility notes section. The pointer to the compatibility notes is the part worth noticing, because a drop-in replacement that needs you to read the compatibility notes is telling you the compatibility is not unconditional. The details of what does and does not carry over are in the Neon guide rather than in this repository, so the honest statement is that the migration target is named and the caveats are documented elsewhere. For @vercel/kv the guidance is @upstash/redis, with a link to the Upstash Redis documentation and its getting started page. The two migrations are not symmetric, and a team that treats them as one exercise will get the details wrong somewhere.

A pnpm and turbo monorepo with a modern toolchain

The repository is a pnpm workspace with turbo driving the task graph, and the root package.json is a small, readable description of how the project is built. The build script runs turbo build, the tests run through turbo test, type checking through turbo type-check, and there is a separate check task plus a publint task that runs publint across the workspaces. The release script is pnpm build followed by changeset publish, and version-packages runs changeset version, reinstalls with the lockfile not frozen, and stages the result. Linting and formatting go through Biome, with a check:fix script that writes changes, and a lint-staged configuration that runs biome check --write on JavaScript, TypeScript and JSON files. Husky is wired in through the prepare script, and the dev dependencies pin exact versions for biome 2.4.6, the changesets CLI, husky, jest, lint-staged, publint, ts-jest, turbo 2.9.6 and TypeScript 5.9.3. The package manager is pinned to pnpm 10.33.0 and the engines field requires node 22.11 or newer, so a contributor on an older Node will not get a working checkout without upgrading.

Getting the packages and the integrations set up

There is no install command in this repository, and that is not an omission. The packages are published to npm under their scoped names, and the README points you at the documentation for each one, at vercel.com/docs/storage/vercel-blob for the object storage package and vercel.com/docs/storage/edge-config for the configuration package, with the full storage documentation at vercel.com/docs/storage. The other installation route the README describes is not npm at all but the Vercel Marketplace, where third-party postgres and KV solutions attach to a Vercel project as native integrations. The repository does not include a quick start, a sample application or a local development guide, so there is nothing here to copy for a first use. What the tree does contain is the machinery of the project itself, with packages/ holding the published code, tooling/ holding the build and test tooling, test/ for tests, a .changeset/ directory for the release notes workflow, renovate.json for dependency updates, a .node-version file, and a turbo.json for the task configuration. The integration test story is visible in the scripts, with an integration-test task and a run-integration script that starts the vercel-storage-integration-test-suite package in development mode, which is where you would look to see how the packages are exercised against a real deployment.

What the two surviving packages are for

The README is not a feature document, so the scope of each package comes from one line each, and it is enough to decide whether you need them. @vercel/blob is fast object storage, which is the direct answer to the question of where an application puts a file that is not code, an upload, an image or an export, when you do not want to run a bucket yourself. @vercel/global-config is for ultra-low latency data reads, which is a narrower problem: configuration and small pieces of state that an edge function needs on every request, where a round trip to a regional database would be the dominant cost. The pairing is the point. A serverless deployment on Vercel has no local disk, so the storage primitives it does have are object storage for bulk and a fast key value read path for hot configuration. Neither package is a database in the relational sense, and neither replaces the Postgres or KV products that were withdrawn, which is exactly why the README keeps a migration section for those rather than presenting a replacement.

Where Vercel Storage is the wrong choice

Three limits. The first is the obvious one: these are storage services tied to a hosting platform, with a Vercel project, a Vercel account and a Vercel billing relationship. If your application is deployed somewhere else, or your data residency requirements forbid that, or you want the storage layer to survive a change of hosting, then a self-managed object store and a key value store you operate will serve you better even though you will do more work. The second is that the surface is narrow and the top of the shelf is empty. The two remaining packages cover object storage and edge configuration and nothing else, and the parts of the original line that covered relational data and general key value are now third-party integrations from the Marketplace, which means the guarantees, the SDK and the operational story are the provider's rather than Vercel's. The third is the version churn in the surviving package. @vercel/blob moved from 2.8.0 on 2026-08-10 to 2.8.1 on 2026-10-06 and 2.8.2 on 2026-10-14, so a pinned dependency is worth keeping, and the last push to the repository was on 2026-10-14. The repository itself is not the place to look for a long-term compatibility promise about the storage products, since the README of this monorepo is now mostly a deprecation notice.

Editorial conclusion

Adopt @vercel/blob and @vercel/global-config if you want storage that deploys with your Vercel project rather than something you provision and secure yourself, and plan around the deprecations if you still have Vercel Postgres or Vercel KV in your stack, because those products no longer exist and the repository names the replacements, @neondatabase/serverless or the Neon compat package for Postgres and @upstash/redis for KV. Before you migrate, read the Neon transition guide's compatibility notes, because the drop-in replacement claim has conditions attached, and pin the package version you test since @vercel/blob moved from 2.8.0 to 2.8.2 within ten weeks.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vercel/storage on GitHub