Upstash uses tabbed pricing to solve the multi-product pricing UX problem

The Tactic

Upstash offers four distinct products — Redis, Vector, QStash, and Workflow — each with its own pricing model. Instead of creating four separate pricing pages or cramming all tiers into one overwhelming grid, they use a tabbed interface that lets visitors switch between products while staying on the same page.

Each tab reveals a pricing structure specific to that product, with usage-based pricing (per-request or per-operation) as the unifying model. The result is a pricing page that's simultaneously comprehensive and scannable — you see one product's pricing at a time, with the others one click away.

The Multi-Product Pricing Problem

Multi-product companies face a fundamental UX challenge on pricing pages. Show all products at once, and the page becomes a wall of numbers that overwhelms visitors. Show them on separate pages, and visitors can't easily compare costs across the platform.

Upstash's tabbed approach solves both problems. The tabs create visual containment — each product's pricing exists in its own context, preventing cognitive overload. But the tab bar itself creates a persistent menu that lets visitors switch between products without navigation, enabling quick comparison.

This pattern also communicates product breadth without requiring the visitor to discover it. A developer who arrives looking for Redis pricing immediately sees that Upstash also offers Vector, QStash, and Workflow. The tabs function as passive product discovery — every visitor to the pricing page learns about the full platform.

Per-Request Pricing: Speaking Developer Language

Upstash prices by requests and operations rather than by provisioned capacity, seats, or flat tiers. This is a deliberate pricing philosophy that aligns with how developers think about infrastructure costs.

Developers are allergic to paying for idle resources. Provisioned capacity pricing (pay for a server regardless of usage) creates anxiety about over-provisioning and waste. Seat-based pricing (pay per team member) creates friction around adding collaborators. Per-request pricing (pay for what you use) eliminates both concerns.

"Pay as you go" resonates specifically with the serverless mental model that Upstash targets. Serverless developers are already accustomed to usage-based billing from AWS Lambda, Vercel Functions, and Cloudflare Workers. Upstash's pricing model matches this existing expectation, reducing the cognitive overhead of understanding costs.

The transparency is also a trust signal. Per-request pricing is inherently auditable — a developer can calculate their expected costs by multiplying their request volume by the per-request price. There are no hidden multipliers, no surprise overages from hitting a tier boundary, no pricing that requires "talk to sales" to understand.

The Free Tier as PLG Engine

Each of Upstash's products includes a generous free tier defined in concrete terms: 10,000 commands per day for Redis, for example. This specificity is important — it tells the developer exactly how much they can build before paying anything.

Vague free tiers ("free to get started," "limited free plan") create uncertainty. A developer can't plan a project around a free tier they can't quantify. Specific limits (10K commands/day, 1M vectors, 500 messages/day) let developers calculate whether the free tier covers their use case or when they'll start paying.

Specific free tier limits also serve as a qualification mechanism. A developer whose project needs 5K commands/day will self-qualify into the free tier. A developer whose project needs 100K commands/day will self-qualify into a paid plan and already has a ballpark cost expectation before they sign up.

Tab Design Details

Several production choices make Upstash's tabs effective. The currently selected tab has a clear visual indicator (color change or underline), eliminating ambiguity about which product's pricing you're viewing. The tab labels use product names (Redis, Vector, QStash, Workflow) rather than generic labels (Database, AI, Messaging, Orchestration), maintaining brand consistency and product recognition.

The tab order also matters. Redis — Upstash's flagship product — comes first. This ensures the most commonly sought pricing is visible by default, while newer products are discoverable through the tab interface.

FAQ

At what point should a company switch from a single pricing page to tabbed pricing?

When you have 3 or more products with distinct pricing models. Two products can coexist on a single page with side-by-side presentation. Three or more products create too much visual complexity without tabs. The tab pattern also works well for a single product with distinct deployment models (cloud vs. self-hosted, regional vs. global).

Does per-request pricing work for all developer tools?

Per-request pricing works best for infrastructure and API products where usage is measurable in discrete operations. For tools where value is harder to quantify per-request (IDEs, monitoring dashboards, collaboration tools), seat-based or flat-tier pricing may be more appropriate. The key is matching the pricing unit to something the developer can mentally model.

Should the free tier be time-limited or usage-limited?

Usage-limited is almost always better for developer tools. Time-limited free trials create urgency that works against the developer evaluation process — developers may not have time to properly test your product within 14 days. Usage-limited free tiers let developers build real projects without time pressure, creating genuine adoption that converts to paid when the project grows beyond the free limits.