.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
What Pricing Model Works Best for Open Core SaaS Products
Open core SaaS companies face a pricing problem that closed SaaS vendors do not. Their prospects can often download, inspect, and run a useful version of the product without paying. A price list that merely puts a fee on access will therefore fail the most basic buyer test: why pay for something the team can operate itself?
The stakes have risen as infrastructure, observability, developer tools, data platforms, and security products move from departmental experiments to systems that run production workloads. At that point, a vendor must monetize more than code. It must monetize lower operating burden, dependable scale, and the controls that let a business use the software with confidence.
Monetizely's position is clear: the strongest default model for open core SaaS is committed consumption. Charge primarily for a measurable production workload, pair it with a platform minimum or annual commitment, and package governance and support around the managed service. Do not make a seat fee, a source-code license, or a flat hosting charge the main engine of growth.
The free core earns adoption, while the paid service must earn accountability
Open core works because the free product is real. Developers can validate architecture, run a proof of concept, and retain a credible exit option. That freedom drives adoption, but it also makes arbitrary feature gates and generic hosting markups fragile.
GitLab states that its open core is published under an MIT license, while customers can also install and manage GitLab themselves. Grafana similarly offers a free, self-managed open-source edition, alongside commercial Enterprise and Cloud offerings. Supabase lets customers self-host, but assigns them responsibility for server maintenance, security hardening, database operations, backups, monitoring, and uptime. Those responsibilities are precisely where a managed SaaS offer can create value.
The market evidence shows four different commercial expressions of the same logic. Every company preserves a low-friction path into the product, then charges when production use creates ongoing value or operational responsibility.
Exhibit 1: Open core vendors monetize the managed workload, not basic access All pricing and product facts below were available on September 7, 2026.
| Vendor | What remains accessible without a large contract | Paid commercial design | Pricing signal |
|---|---|---|---|
| GitLab | An open core under MIT licensing and self-managed deployment options | Paid plans add advanced collaboration, support, security, compliance, and governance; AI consumption is also separately metered | Premium is listed at $29 per user per month, billed annually; on-demand GitLab Credits are $1 per credit after included or committed credits. (about.gitlab.com) |
| Grafana | Grafana OSS is free and self-managed | Grafana Cloud sells a managed telemetry stack, while Enterprise adds commercial features and support | Cloud Pro includes a $19 monthly platform fee; logs begin at $0.050 per GB processed, and Enterprise has a $25,000 annual minimum commitment. (grafana.com) |
| PostHog | A generous cloud entry point and open-source product roots | Product analytics expands as the customer captures more product activity | Product Analytics includes 1 million events per month free, then lists $0.00005 per event. (posthog.com) |
| Supabase | A self-hosted option for teams willing to operate the stack | Managed database, backups, scaling, support, security controls, and organization features | Pro starts at $25 per month; it includes 100,000 MAUs, then charges $0.00325 per MAU, plus separate compute, storage, and egress charges. (supabase.com) |
The pattern is decisive: open core products convert free users when the price rises with live workload, while the paid package removes operating work and adds controls that a production buyer can defend internally.
Monetizely's 5-Step Pricing Framework puts decisions in a sequence that prevents the price point from becoming the first and loudest debate. The five steps are Goals and Segmentation, Packaging, Choosing the Right Pricing Metric, Finding the Right Price Points, and Operationalizing Pricing. As developed in Monetizing Agentic AI, the sequence matters because a company cannot sensibly set a rate until it knows which customer it is serving, what that customer is buying, and what unit of use best reflects the value delivered.
For an open core company, each step answers a commercial question that a closed SaaS vendor can often postpone. The framework pushes leadership to resolve those questions before adding another tier or discount.
Exhibit 2: The five decisions that turn an open product into a durable SaaS business
| Step | Decision for an open core company | Strong answer |
|---|---|---|
| Goals and Segmentation | Is the company seeking rapid developer adoption, enterprise expansion, margin protection, or a combination? | Separate individual builders, growing production teams, and regulated enterprises before designing plans. |
| Packaging | What does each segment need beyond the downloadable product? | Package managed operations, security, support, deployment controls, and service levels around real buyer needs. |
| Pricing Metric | What measurable unit grows when the customer receives more value? | Use a production workload such as events, data processed, compute capacity, active end users, or protected assets. |
| Price Points | How should the company charge for entry, scale, and large commitments? | Provide a useful free threshold, clear unit rates, volume discounts, and annual commitments for larger accounts. |
| Operationalizing Pricing | Can the customer see, forecast, and audit the bill? | Define the meter precisely, show usage in-product, alert before overages, and make invoices reconcilable. |
The framework leads to a simple commercial conclusion: the metric is not a billing detail. It determines whether the managed service has a credible economic reason to exist.
A good open core pricing metric must do three jobs at once. It should rise as customer value rises, protect the vendor when cloud costs rise, and remain relevant even though the customer could run core software elsewhere.
A named user often fails that test. A 50-person company may operate one small deployment or a global service processing billions of events. Charging both accounts mainly by employee count ignores the workload that creates cost and value. It also gives the buyer a strong argument for self-hosting: “Why should we pay more because more people can view the product?”
Usage metrics avoid that trap when they measure work the managed service actually performs. PostHog bills analytics events. Grafana prices logs, traces, metrics, and related telemetry. Supabase charges across several production dimensions, including active users, database size, compute, and egress. These meters are not interchangeable, but each maps to a real operating load.
The following scoring table makes the choice concrete. Scores reflect Monetizely's assessment for a typical open core platform sold as a managed SaaS service.
Exhibit 3: Production usage outperforms seats as the default open core meter
| Candidate primary meter | Tracks managed-service value | Follows cloud cost | Still works when free core exists | Buyer can forecast spend | Overall score |
|---|---|---|---|---|---|
| Named user or seat | 2/5 | 1/5 | 2/5 | 5/5 | 10/20 |
| Flat account fee | 2/5 | 1/5 | 1/5 | 5/5 | 9/20 |
| Production workload - events, GB, compute hours, MAUs, jobs | 5/5 | 5/5 | 5/5 | 4/5 | 19/20 |
| Business outcome | 5/5 | 2/5 | 4/5 | 2/5 | 13/20 |
The implication is not that every company should charge per event. It should select one primary unit that captures the product's core production activity, then use secondary meters only where costs materially differ.
For an observability company, that unit may be data processed or retained. For a database platform, it may be compute capacity combined with active application users. For a data integration platform, it may be compute capacity or jobs completed. Buyers will accept different units, but they will reject a meter that bears no visible relationship to what the managed service does for them.
Pure pay-as-you-go pricing maximizes trial conversion, but it can make annual planning difficult for a larger customer. Finance leaders want a number they can approve. Procurement teams want clear boundaries. The vendor needs a committed revenue base that supports support, security, and capacity planning.
The answer is a two-part architecture with one named primary meter: committed consumption based on production usage. The annual commitment is not a second primary meter. It is a financial commitment that the customer spends against the same production unit.
Grafana illustrates the structure clearly. Its self-service Cloud Pro plan includes a $19 monthly platform fee and then charges for usage, while its Enterprise plan starts with a $25,000 annual commitment and scalable unit pricing. Supabase takes a similar path at a smaller-account level, beginning with a $25 monthly Pro plan, including quotas, then charging for usage beyond those thresholds.
A well-designed commercial architecture has four mechanics:
- A platform minimum that covers access to the managed control plane, baseline support, and a useful included allowance.
- One primary production meter that drives expansion as the customer's live workload grows.
- Published or contractually clear unit rates so buyers can model marginal spend before they deploy.
- A committed annual spend level for larger customers, with usage drawing down against the commitment and defined true-up terms.
Exhibit 4: Committed consumption creates a clear path from trial to enterprise scale
The table matters because it preserves a single economic story as the customer grows. The buyer does not need to learn a new metric at every stage, and the vendor does not need to force a successful product into a seat model merely to create annual contract value.
Open core companies often make a costly packaging mistake: they scatter essential enterprise capabilities across arbitrary plan tiers, then use discounting to repair the resulting mismatch. Customers buy features they do not need, while larger accounts negotiate around features they consider mandatory.
A stronger design separates the product into three commercial layers. The core remains useful. The cloud service removes operational work. The enterprise offer addresses organizational risk.
Exhibit 5: Packages should reflect who is buying, while the usage meter remains constant
| Offer | Primary buyer need | Appropriate inclusions | What should not change |
|---|---|---|---|
| Open core and free entry | Evaluation, development, and small-scale use | Functional core product, documentation, community support, bounded free usage | The customer should still recognize the same core product and workflow |
| Managed growth offer | Production speed and reduced operating burden | Hosting, managed upgrades, backups, standard support, included production capacity | The primary usage meter |
| Enterprise offer | Control, accountability, and procurement readiness | SSO, role controls, audit logs, private networking, compliance support, premium support, service levels | The primary usage meter and its basic definition |
GitLab's current structure supports this principle even though it retains seats as a major billing element. Premium is positioned around enhanced productivity and collaboration, while Ultimate adds security, compliance, and governance capabilities. Its newer AI features also use included and on-demand credits, acknowledging that variable compute-heavy activity does not fit cleanly inside an unlimited seat price.
The lesson is not to copy GitLab's exact price card. The lesson is to make enterprise controls a reason to choose a higher package, while keeping the expansion engine tied to the workload that grows after deployment.
Seat pricing remains useful in a narrow but important class of open core products. It works when a distinct person repeatedly uses the product, the value is mainly created through that person's workflow, and incremental usage does not create sharply higher delivery costs.
A company should use seats as its primary meter only when all three conditions hold:
- Each paid user has a clear, recurring role in the workflow, such as a developer approving code or an analyst authoring governed dashboards.
- A heavy customer does not create materially higher infrastructure cost merely by being more successful.
- The commercial value comes from human collaboration, permissioning, and standardization rather than from a large underlying production workload.
GitLab is closer to that case than an observability or database platform. Its per-user pricing fits a collaborative DevSecOps environment, but its compute minute allocations and usage-priced credits show where the seat model reaches its limit.
Most open core infrastructure products should resist the temptation to treat user count as an easy shortcut. It is easy to explain, but ease of explanation is not the same as value alignment.
A usage model fails when customers cannot answer three questions: what is being counted, what has been consumed, and what will next month's bill look like? Those questions become more important in open core SaaS because the buyer always has the alternative of operating the software independently.
Supabase documents its included quotas and overage rates across MAUs, egress, database size, storage, function invocations, realtime messages, and connections. Grafana provides usage documentation across metrics, logs, traces, host hours, and active users. The operational lesson is practical: a consumption model earns trust only when the vendor exposes the same data that drives the invoice.
Before launch, pricing leaders should ensure that the business can do the following:
- Define each billable event in product terms that an administrator can verify.
- Show current usage, included allowances, and expected overages in the customer account.
- Alert customers before they cross meaningful thresholds rather than after an invoice arrives.
- Give sales, support, finance, and customer success the same source of truth for entitlement and usage.
A precise rate card cannot compensate for opaque metering. In open core, an unexplained bill does more than create a support ticket. It strengthens the case for self-hosting.
Committed consumption preserves the trust that open core creates
Open core succeeds when customers believe they retain freedom. The commercial model should reinforce that belief, not punish it. Charging for production workload gives customers room to start small; charging a platform minimum and annual commitment gives the vendor a sustainable account model; packaging governance and support gives larger buyers a reason to expand.
Monetizely's position is therefore not a generic blend of pricing methods. It is a specific architecture: a managed-service subscription with committed consumption, anchored on one production-usage meter. Seats may remain in the price card where human collaboration is truly central, but they should not be the default answer for products whose cost and value grow with data, compute, events, or live application activity.
Make the managed service the economic center of the business. Treat self-hosting as an adoption and trust channel, then measure conversion into managed production use rather than trying to force every open-source user into a paid contract.
Choose one expansion metric before adding more plans. If the leadership team cannot name the production unit that should grow ARR, more tiers will only create more discounting and billing exceptions.
Build annual commitments around the same unit used in self-service. Do not move customers from events or capacity to a vague enterprise license simply because the deal is larger.
Set package boundaries around organizational risk. Reserve security controls, service levels, support depth, private deployment options, and procurement support for higher-value offers.
Use seat pricing only after proving that seats predict both value and cost. When a customer's spend should rise because its workload grows, charge for that workload directly.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- GitLab, “Pricing” and “GitLab for Open Source,” accessed September 7, 2026. (about.gitlab.com)
- Grafana Labs, “Grafana Pricing” and “About Grafana,” accessed September 7, 2026. (grafana.com)
- PostHog, product pricing page, accessed September 7, 2026. (posthog.com)
- Supabase, “Pricing & Fees,” “About Billing on Supabase,” and “Self-Hosting,” accessed September 7, 2026. (supabase.com)