Scale with confidence: Introducing resource‑based pricing

If pricing makes you nervous, you build less.

We’ve seen that first‑hand. When your bill swings with every spike in documents or searches, teams hesitate to ship, and finance can’t forecast.

Our philosophy towards building Meilisearch – from our dual licensing model to how we price – has always centered on giving our customers maximum flexibility.

That’s why we’re introducing resource-based pricing: a developer-first model that stabilizes spend, aligns pricing with actual infrastructure, and provides clear controls over your performance and infrastructure.

Why we’re adding another pricing model

For a while, usage‑based pricing looked like the obvious path. It matched the serverless zeitgeist and mapped neatly to “documents” and “searches.” But reality didn’t fit the abstraction:

• Unpredictability drove churn. Teams with a large amount of data and relatively few searches were penalized. Bills rose in ways that were hard to anticipate.
• Identical “units” did not have identical costs. A million tiny product records and a hundred thousand large PDFs do not consume the same resources – yet usage pricing treats them the same.
• We were over‑optimizing for plan limits. Internally, we found ourselves hand‑tuning infrastructure to fit plan boxes rather than letting customers scale the resources they needed.

Customers (especially developers and CTOs) told us what they wanted instead: price stability, performance control, and transparency on what drives cost.

What “resource‑based” means

With resource‑based pricing, you select dedicated compute for your project – and you pay only for those resources.

• Compute: choose the CPU and RAM you want. Those resources are dedicated to your project via predefined tiers (e.g., XS through 4XL self‑serve; larger tiers via Sales).
• Storage: storage auto‑scales and isn’t customizable at the moment.
• No caps on “documents” or “searches.” Your resources define your limits and performance – scale them up or down as your needs change.

You can upgrade resources self‑serve. At the moment, downgrades are available via support, but very soon you’ll be able to do them from the Cloud interface.

Billing is at the team level. You can run mixed billing in the same invoice (usage‑based projects alongside resource‑based ones), and you can upgrade/downgrade resources as you go (downgrades via support for the moment, as mentioned above).

This mechanism is the same for both self-serve and enterprise. The Enterprise level then adds SLAs, SSO, support/SLOs, volume discounts, and optional add‑ons – not different machines.

Why this is better for teams needing to scale:

• Predictability: stabilize spend as you grow – no more surprise overages tied to abstract units.
• Control: developers can dial resources to match performance goals – whether that’s sub‑second search or faster indexing.
• Transparency: your bill tracks real cost drivers (CPU, RAM, storage), making budgeting (and explaining costs) far easier.

It also improves activation. If indexing or search feels slow, you can bump resources for a few cents per hour to validate your use case, then tune back once you’ve optimized.

The developer experience: monitor, tune, repeat

Alongside the pricing model, we’re rolling out a new Infrastructure tab in the Cloud UI so you can see what’s happening under the hood:

The new interface allows you to monitor CPU, memory, and storage usage live and take action proactively to avoid performance issues.

Coming soon are also alerts and recommendations. You’ll be able to set up proactive alerts when resource usage reaches certain thresholds (e.g., 80/90/95%) to avoid outages and slow performance.

Wherever possible, we’ll suggest optimizations first (configuration and data‑model tips), then scaling guidance if you still need more headroom.

How does this fit with usage‑based (we’re keeping both)

This isn’t an either/or ideology. It’s a toolbox:

• Start with usage‑based if you want near‑zero friction and the simplest mental model for a quick evaluation.
• Switch to resource‑based when predictable spend and performance control become more important than per‑unit simplicity.

We’re not forcing migrations. Existing plans are grandfathered. Going forward, when you create a project, you’ll be able to choose usage‑based or resource‑based in the flow – and mix them across a team as your portfolio grows.

Add‑ons and future flexibility

Some capabilities sit above pricing mode:

• Team‑level add‑ons: SSO, SOC 2, analytics, merchandising
• AI services as first‑class add‑ons on a single Meilisearch bill: embeddings (by size), LLM tokens, re‑ranking models
• Horizontal scale via sharding (multiple machines per project) for advanced workloads

Bandwidth billing and alerting are planned future improvements.

What to expect at launch

• Fully functional backend: applicable to any new or existing project; resource upgrades are self‑serve; downgrades via support
• Team‑level billing with mixed cycles: usage‑based and resource‑based projects on one invoice
• New Infrastructure tab in the dashboard to monitor CPU, memory, and storage
• Self‑serve and enterprise both supported; enterprise layers on support and governance – not different pricing mechanics

We are confident this new pricing model will lead to lower churn and faster activation because customers can plan with confidence and validate performance without friction.

Choosing the right model (quick guide)

Choose usage‑based if:

• Business stakeholders lead the evaluation
• Traffic is modest and bursty
• You want the simplest on‑ramp

Choose resource‑based if:

• You’re a developer/CTO who needs predictable spend
• You want explicit control over performance via CPU/RAM
• Your data shape doesn’t map cleanly to “documents/searches”

How to try it

• New projects: pick “Resource‑based” when creating a project.
• Existing projects: talk to our support team to switch to resource‑based pricing.
• Then, visit the Infrastructure tab to monitor resource usage and adjust CPU/RAM as needed. If you want help optimizing before scaling up, talk to us – we’re happy to review settings and tradeoffs with you.

Our goal

Pricing should reflect reality, not get in your way. Resource‑based pricing puts control back in developers’ hands and makes your bill as predictable as your architecture.

I’m excited to see what you build when pricing is finally one of the simplest aspects of running a search engine.