Vercel's own storage products, and when to reach for something else instead
Vercel offers its own KV store, Postgres database, and Blob storage, each convenient precisely because they're one click away inside the same dashboard already managing your deployment. That convenience is real — and it's also exactly the kind of trade-off worth understanding before committing to it for something that outgrows it.
Intermediate
2 min read
What Vercel's own storage products actually are
Vercel KV — a Redis-compatible key-value store (actually a managed Upstash Redis instance under the hood), for the same caching/session-storage use cases Caching Strategies' own domain covers.
Vercel Postgres — a managed Postgres database (actually Neon under the hood), serverless-friendly with connection pooling handled for you.
Vercel Blob — object storage for files (images, uploads), conceptually similar to AWS S3 (AWS's own domain covers S3 directly).
Each one is genuinely convenient specifically because it's configured from inside the same dashboard already managing the deployment — one environment variable appears automatically, no separate account or billing relationship to set up for a small project's first database or cache.
The real trade-off: convenience now, versus capability and portability later
Vercel's own Postgres offering (via Neon) is a real, capable Postgres database — but it's deliberately scoped toward the serverless-connection-friendly use case, without Supabase's own built-in Row Level Security, auto-generated REST API, realtime subscriptions, or built-in auth (Supabase's own domain, covered next, goes deep on exactly these). Reaching for Vercel Postgres for a quick project that genuinely just needs a database is entirely reasonable; reaching for it when the actual requirement is "users need their own isolated data, enforced at the database level" reintroduces, in application code, exactly the access-control work Supabase's Row Level Security would have handled declaratively instead.
Why "it's already in my Vercel dashboard" isn't always the right deciding factor
Quick prototype, simple key-value cache → Vercel KV is genuinely fine
A real app needing auth + per-user row access → Supabase's RLS does this natively;
Vercel Postgres alone does not
Large file uploads, needing fine-grained → Depends — Vercel Blob for simple
access rules per user cases, S3 (AWS) for complex ones,
Supabase Storage if already using
Supabase for everything else
The actual decision criterion is the same one this curriculum's other infrastructure domains have applied repeatedly: does the simpler, more convenient option's feature set genuinely cover the real requirement, or does it merely avoid an extra signup step while requiring the missing features to be rebuilt by hand in application code anyway. A team already deep in Vercel's ecosystem for deployment doesn't automatically need Vercel's data products too — the deployment platform and the data layer are two separate decisions, even though Vercel's dashboard makes it tempting to treat them as one.