PostHog Feature Flag Pricing Bills Per Request, Not Per Seat

PostHog feature flag pricing is metered per evaluation request, not per flag, per seat, or per monthly active user. The first 1,000,000 requests to the /flags endpoint each month are free. After that, PostHog’s published rate card charges $0.0001 per request from 1–2M, $0.000045 from 2–10M, $0.000025 from 10–50M and $0.00001 above 50M (posthog.com/pricing). Five million requests costs $235: 1M free, plus 1M at $0.0001 ($100), plus 3M at $0.000045 ($135). Rates are marginal, so crossing a band never reprices the volume below it.

Every figure on this page is arithmetic derived from published rates and public documentation. Nothing here is a measurement.

Visual needed: Diagram showing that one /flags request bills once regardless of how many flags the project contains Visual spec: two side-by-side projects, one with 2 flags and one with 200, both resolving a single /flags call. Same meter reading on both.

PostHog feature flag pricing in 60 seconds

The billable unit is the HTTP request, and the number of active flags in your project does not change what a request costs. Two flags or two hundred, the request bills once (cutting costs docs).

Three mechanics push real bills above a naive estimate.

• Experiments share the meter. A/B test evaluation traffic lands in the same feature flag line item. There is no separate experiments charge (pricing page).
• Surveys evaluate flags. Survey display conditions resolve through /flags, so a survey-only project can accrue a flag bill.
• Local evaluation bills 10 credits per poll. One always-on backend at the default 30-second interval is charged 864,000 requests a month before a single user arrives.

The free plan covers 1 project with 1-year retention and community support. Adding a card raises that to 6 projects, 7-year retention and email support while the monthly free volume stays the same (pricing page). PostHog claims its free tiers mean “more than 90% of companies use PostHog for free”. That is a vendor self-claim and is not independently verified.

The full feature flag rate card

Competitors reprint the marginal rates. Nobody publishes the cumulative cost, which is the number a buyer actually needs.

Monthly /flags requests	Price per request	Marginal cost of the band	Cumulative cost at top of band	Blended rate at that point
First 1,000,000	$0	$0	$0	$0
1M – 2M	$0.000100	$100.00	$100.00	$0.000050
2M – 10M	$0.000045	$360.00	$460.00	$0.000046
10M – 50M	$0.000025	$1,000.00	$1,460.00	$0.0000292
50M – 100M	$0.000010	$500.00	$1,960.00	$0.0000196

Rates as published on posthog.com/pricing. Cumulative and blended columns computed from those rates. Re-verify this page monthly against the pricing page and the changelog.

Visual needed: Cost curve of monthly spend and blended rate per request against /flags volume Visual spec: X-axis = monthly /flags requests, 0 to 100M, log scale. Series 1 = total monthly spend from the tiered arithmetic above. Series 2 = blended rate per request on a secondary axis, showing the flattening from $0.00005 to $0.0000196. Label it “derived from published rate card, not measured”.

Two clarifications prevent misreadings of PostHog feature flag pricing. Rates are marginal: reaching 3M requests does not charge the first 2M at $0.000045. And $feature_flag_called events are optional analytics events, not the billing unit. Their count has no fixed relationship to billable request volume, so a Trends chart of that event is a diagnostic signal, not an invoice (cutting costs docs).

What actually counts as a billable request

Action	Bills a /flags request?	Notes
posthog-js / React Native SDK init	Yes	The init fetch populates the client cache
identify()	Yes	Triggers a re-fetch because flags depend on distinct_id
Person property update	Yes	Properties can change flag targeting, so flags re-evaluate
Group creation / group property set	Yes	Group-targeted flags must be recomputed
reloadFeatureFlags()	Yes	Explicit re-fetch
Survey targeting evaluation	Yes	Checks all active flags in the project
Server-side getFeatureFlag() / isFeatureEnabled() / getAllFlags()	Yes	Unless local evaluation resolves it in-process
Client-side getFeatureFlag() after init	No	Reads the cached response
Local evaluation resolved in-process	No per-call charge	The poll is charged instead, at 10 credits
Bootstrapped flag values on first render	No	Values arrive with the page payload

Sources: cutting costs docs and the /flags API reference.

The rule most teams miss: a request bills if it evaluates at least one active billable flag, even when your code never checks that flag. Deleting flags does not cut the bill. Cutting requests does.

Response shape matters operationally. /flags?v=2 returns evaluations only; /flags?v=2&config=true returns evaluations plus client configuration such as replay and survey settings (API reference). Pick one shape and parse it consistently, because quota state surfaces in both but in different places.

errorsWhileComputingFlags returns true when PostHog could not compute some flags, which lets clients apply partial updates to the flags that did resolve. A partial response is still a billed request. Failure does not refund.

Visual needed: Request lifecycle diagram with billable moments highlighted for one page load and one server request Visual spec: billable moments marked (init, identify, property update, group creation, explicit reload, survey targeting), with a second path showing bootstrapping removing the init round trip.

The local evaluation trap: why one idle server costs 864,000 requests a month

Each local evaluation poll is charged as 10 feature flag requests, and posthog-node, posthog-python, posthog-ruby, posthog-go and the other server SDKs poll every 30 seconds by default (cutting costs docs).

PostHog publishes the arithmetic: 10 × 2 polls per minute × 60 × 24 × 30 = 864,000 requests per month, per server, per PostHog instance. One always-on backend consumes 86% of the free tier while serving zero users.

Always-on instances	30s (default)	60s	5 min	10 min
1	864,000 req · $0	432,000 req · $0	86,400 req · $0	43,200 req · $0
3	2.59M req · $126.64	1.30M req · $29.60	259,200 req · $0	129,600 req · $0
10	8.64M req · $398.80	4.32M req · $204.40	864,000 req · $0	432,000 req · $0
25	21.6M req · $750.00	10.8M req · $480.00	2.16M req · $107.20	1.08M req · $8.00

Assumptions: 100% uptime, 30-day month, one PostHog client per instance, no user-facing traffic at all. Priced with the tiered rate card above. The 10-instance/30s figure breaks down as 1M free + 1M at $0.0001 ($100) + 6.64M at $0.000045 ($298.80).

Visual needed: Heatmap of polling cost by instance count and poll interval Visual spec: cells labelled with monthly requests and dollars, colour-scaled by cost, with the 1M free-tier boundary drawn as a contour line. A ten-replica Kubernetes deployment sits in the red band at the default interval.

The tradeoff is real. Moving from 30 seconds to 5 minutes cuts polling cost roughly tenfold, and it also means a flag toggled in the PostHog UI takes up to five minutes to reach your servers. For a kill switch during an incident, five minutes is a long time. Keep kill-switch flags on remote evaluation so they propagate immediately, and let the slow poll cover the boring permanent flags.

Visual needed: Chart plotting polling spend against flag propagation latency for four poll intervals Visual spec: dual-axis line, 30s / 60s / 5min / 10min on the X-axis, dollars per month on the left axis, worst-case propagation delay on the right.

PostHog’s docs advise against local evaluation in edge runtimes such as Cloudflare Workers, or in AWS Lambda, because a PostHog instance is initialised on every invocation, which can raise the bill drastically (cutting costs docs). The failure shape is easy to picture: a function at 1,000,000 invocations a month, each initialising a client that polls at least once, bills 10,000,000+ requests. That is $460 for work remote evaluation would have done for $100.

The decision rule: local evaluation pays off only when a single instance evaluates far more flags than its polling baseline of 864,000 per month. Below that threshold, remote evaluation is cheaper and fresher.

Visual needed: Decision tree for choosing local or remote flag evaluation Visual spec: serverless/edge → remote. Always-on → evaluations per instance per month above 864,000? → yes → kill-switch latency tolerance → recommended poll interval (30s / 60s / 5min). Below threshold → remote.

Cost models for five real architectures

PostHog documents a workable estimation method: open the Chrome network tab, count /flags requests per page refresh, multiply by monthly pageviews. Their worked example is 2 requests per pageview across ~150,000 monthly pageviews, which is about 300,000 requests a month (cutting costs docs). Extending that method to other stacks produces the table below.

Architecture	Requests per unit of traffic	Stated traffic level	Monthly requests	Monthly cost	Dominant driver	Best lever
Classic SPA (posthog-js)	~2 per pageview (init + identify)	1M pageviews	2.0M	$100	Pageview count	Bootstrap; advanced_disable_feature_flags_on_first_load
Classic SPA, high traffic	~2 per pageview	10M pageviews	20M	$710	Pageview count	Bootstrap flag values at render
Next.js SSR, unbootstrapped	~2 per pageview (server eval + hydration fetch)	10M pageviews	20M	$710	Duplicate client fetch	Bootstrap into the initial payload
Next.js SSR, bootstrapped	~1 per pageview	10M pageviews	10M	$460	Server-side evaluation	Cache per session
Always-on backend, remote eval	1 per flag-gated endpoint call	5M gated calls	5.0M	$235	Code paths executed	Consolidate checks per request
Always-on backend, local eval	864,000 per instance	10 instances	8.64M	$398.80	Poll interval	Raise interval to 5 min
Mobile (React Native SDK)	~1 per cold start (preloadFeatureFlags)	200k MAU × 20 cold starts	4.0M	$190	Cold starts	Cache across launches

Assumptions box: 30-day month, requests-per-pageview taken from PostHog’s own 2-per-pageview example, 100% backend uptime, default 30-second poll, 20 cold starts per mobile user per month. The single assumption that dominates every row is requests per unit of traffic. Halve it and most rows halve. Substitute your own number from the network tab before trusting any figure here.

Visual needed: Bar chart of monthly flag spend across seven architectures Visual spec: horizontal bars ordered by cost, each annotated with its dominant driver, with the bootstrapped and unbootstrapped Next.js bars paired to show the $250 delta.

The Next.js case deserves its own note because it is the highest-traffic query variant and no ranking page prices it. A server component evaluates a flag during render, the browser hydrates, posthog-js initialises and fetches flags again. Two billable requests for one pageview. Bootstrapping the server’s evaluation result into the initial payload removes the second one, which at 10M pageviews is the difference between $710 and $460. See bootstrapping feature flags guide and Next.js flag implementation.

Mobile teams rarely buy flags alone. Mobile session replay is metered separately at 2,500 free recordings then $0.0100 per recording, so 10,000 recordings adds $75 to the same invoice (pricing page). Web session replay starts at 5,000 free recordings, then $0.0050 to 15k, $0.0035 to 50k, $0.0020 to 150k, $0.0017 to 500k and $0.0015 above. Details in PostHog session replay pricing.

The three surcharges nobody documents

Surveys ride the flag meter. Survey targeting evaluation checks all active feature flags in the project through /flags, and Surveys depend on flags internally. A team that bought PostHog for surveys and never wrote a flag can still generate feature flag charges. The fix is advanced_only_evaluate_survey_feature_flags: true, which still makes the request but skips evaluating regular flags, so those are not charged (cutting costs docs).

No native flag environments. PostHog issue #13160, “Feature Flag Environments to make testing easier”, is open. Until it ships, staging, CI and demo traffic bills against the same organisation quota as production, and clutters the production flag list. Documented workarounds: advanced_disable_feature_flags: true in JS, preloadFeatureFlags = false on mobile, and bootstrapped or locally overridden values in CI.

Forgotten environments. An abandoned demo app sends no events and still polls /flags for flags, replay config and surveys. The audit recipe from PostHog’s docs: build a Trends insight on $feature_flag_called or $identify, set chart type to Table, and break down by $lib, $lib_version, $host, $device_name and $app_version over the last 30 days. Anything you do not recognise is a line item (cutting costs docs).

Visual needed: Annotated screenshot of PostHog’s billable usage dashboard template Visual spec: the dashboard template from the public cutting-costs doc, credited and linked, with callouts on the feature flag request series and the $lib breakdown.

Billing limits, quota limiting and what your app does when the meter stops

Feature flag billing limits are set per product at the organisation level and shared across all projects in that organisation (cutting costs docs). A runaway staging project can therefore exhaust the production allowance.

The failure behaviour is specific. On exceeding quota, /flags returns a quota-limited response carrying a quotaLimited field containing feature_flags, SDKs fall back to defaults (false for isFeatureEnabled(), null for getFeatureFlag()), the response carries a quota_limited property, and debug mode logs a warning (cutting costs docs, API reference).

Read that again as an engineering statement rather than a billing one. If a flag is a kill switch, or gates a paid feature, “everything defaults to false” is a production behaviour change triggered by an accounting event.

Quota state appears in both /flags?v=2 and /flags?v=2&config=true, in different positions within the payload. Code that parses only one shape can misread the state entirely and silently.

Visual needed: Sequence diagram of an SDK call after the feature flag quota is exhausted Visual spec: client → /flags → quota-limited response → SDK default value → user-visible behaviour, with the kill-switch branch flagged in red.

Pre-launch guardrail checklist:

• Set a per-product billing limit, and size it against the local evaluation baseline, not against user traffic.
• Wire the debug-mode warning into your real logger.
• Alert on the quota_limited property, in the same dashboard as flag request volume.
• Confirm, flag by flag, that the default branch is the fail-safe branch.
• Confirm your staging organisation is separate, or that staging flags are disabled.

Platform packages: what Boost, Scale and Enterprise add on top

Platform packages are flat monthly add-ons that sit on top of usage-based charges. They do not include usage and they do not lower the per-request rate, which is the structural fact that matters most for PostHog feature flag pricing at enterprise scale.

Package	Buying trigger it answers	Representative capability
Boost	Compliance ask	2FA and SSO enforcement, shared-resource access settings
Scale	Security review	SAML SSO, approval workflows
Enterprise	Audit and procurement	RBAC, 60-month activity logs, dedicated account manager, 8-hour response target, custom MSA and invoicing

Read the monthly price for each package on PostHog’s own pricing page. Third-party summaries of these three numbers disagree with each other, and a flat add-on is the one part of the bill that procurement will quote back at you.

Support runs on a second ladder that buyers routinely conflate with the first. PostHog’s pricing page describes Slack-based support as available above roughly $2,000/month of pay-as-you-go spend, which is a usage threshold rather than an add-on price.

PostHog publishes discounts for startups and non-profits; the route is creating an account and contacting sales. Worth checking if you are a Y Combinator company or otherwise early, because the qualification bar is often lower than buyers assume. Terms move, so confirm them before you budget against them.

How PostHog’s flag pricing model compares to LaunchDarkly, Statsig and the rest

Platforms bill on incompatible units, so any single-number cross-vendor comparison is an assumption stack wearing a fact’s clothing.

Platform	Billing unit	Vendor source
PostHog	/flags requests, 1,000,000 free per month	posthog.com/pricing
LaunchDarkly	Contexts / MAU plus seats	launchdarkly.com/pricing
Statsig	Analytics events and gate checks	statsig.com/pricing
Flagsmith	API requests plus seats	flagsmith.com/pricing
ConfigCat	Configs and seats	configcat.com/pricing
GrowthBook	Seats, with an open-source core	growthbook.io/pricing
Unleash	Open-source edition plus paid hosted plans	getunleash.io/pricing

PostHog, Flagsmith, GrowthBook and Unleash ship open-source editions. LaunchDarkly and Statsig do not.

Read each vendor’s page and date it before quoting any of this. Free tiers and units change without notice, and do not derive dollar totals across the table, because the units do not convert. Split, Harness, DevCycle, Optimizely and Amplitude Experiment sell into the same slot, and OpenFeature-compatible tools such as Flipt and FeatBit turn up in practitioner threads like this Hacker News catalogue.

Visual needed: Comparison graphic mapping each platform’s billing unit to what makes its bill grow Visual spec: seven columns, one per platform, each showing its meter (requests, contexts, gate checks, seats, configs) and the traffic pattern that inflates it.

The comparison currently ranking for this query is vendor content. Statsig’s cost comparison concludes that “Statsig offers the lowest pricing across all usage levels” and that “Statsig is the only tool that provides free feature flags for self-service companies at all stages.” That is marketing published by a direct competitor, not a finding.

Its arithmetic is checkable, which is more interesting than its conclusion. Its stated assumptions include 20 sessions per MAU and one request per session, so 20 requests per MAU. Against PostHog’s 1,000,000 free requests, that implies a free tier reaching roughly 50,000 MAU. The same post asserts that PostHog’s free tier “tends to only hold for MAUs of <5000”. Those two statements cannot both be true under its own model.

Change one assumption and the ranking moves. At two requests per session instead of one, 40 requests per MAU, PostHog’s free tier covers 25,000 MAU. Its other assumptions, 20 gates instrumented per MAU and 50% of gates checked per session, inflate platforms billed on gate checks and deflate platforms billed on requests. Read the methodology sheet before the conclusion.

The honest heuristic: PostHog usually wins when flag traffic is bounded and you already want product analytics, session replay, experiments and surveys on one bill. Per-request billing punishes chatty clients and large always-on local-evaluation fleets harder than seat- or MAU-based models do. Deeper breakdowns in PostHog vs LaunchDarkly comparison, LaunchDarkly pricing explained and Statsig pricing explained.

The cost-reduction playbook, ranked by savings per hour of work

1. Audit for forgotten environments. Highest ratio of dollars saved to minutes spent. Use the $lib / $host breakdown above. An old staging box can be switched off in an afternoon.
2. Fix local evaluation. Raise the poll interval, or drop local evaluation on services that evaluate fewer than 864,000 flags a month. Remove it from edge runtimes and Lambda entirely.
3. Bootstrap instead of fetching on init. Structural, not a config tweak: load flag values into the client from the server render and the init round trip disappears. This is the Next.js fix from the cost model table.
4. Disable flags in CI and staging. advanced_disable_feature_flags: true stops automatic fetching, and it disables Surveys, because Surveys rely on flags internally. advanced_disable_feature_flags_on_first_load skips only the init fetch, and an immediate identify() will still trigger one.
5. Restrict survey-only projects. advanced_only_evaluate_survey_feature_flags: true keeps the request but stops regular flag evaluation and its charge.

Visual needed: Ranked chart of the five cost levers by dollars saved per hour of engineering work Visual spec: five bars, each split into estimated monthly saving and estimated hours to implement, ordered by the ratio.

Measure before optimising. PostHog publishes a billable usage dashboard template; break usage down by event, SDK library and product first, then pick the lever (cutting costs docs). Related reading: local vs remote evaluation tradeoffs and feature flag lifecycle management.

Self-hosting to avoid the flag bill

The PostHog/posthog repository is public and under active development. Star counts, open issue totals and release tags move weekly, so read them at the source rather than from a page like this one.

Licensing needs care. GitHub reports the repository licence as NOASSERTION rather than a single SPDX identifier, while PostHog’s pricing page describes its open-source product as MIT licensed. Read the LICENSE file and any enterprise-directory terms yourself before assuming self-hosting is unrestricted. The repository metadata does not support a clean one-word answer.

Self-hosting swaps a per-request bill for ClickHouse infrastructure, upgrade work and on-call rotation. For flags alone, that trade almost never beats a 1,000,000-request free tier. It becomes a real decision when data residency drives the requirement and US Cloud or EU Cloud will not satisfy your regulator. PostHog frames its open-source product as existing for organisations “not ready to move to PostHog Web yet”, which is the vendor’s positioning rather than an independent assessment. More in self-hosting PostHog infrastructure costs.

Roadmap gaps that affect what you’re paying for

Issue	Title	Reactions	Why it affects your bill or rollout
#25726	Product tours / guides	953	Highest-signal open request in the repo. Today’s workaround is flags plus surveys, and that workaround carries flag request cost
#14330	End-user-facing analytics for B2B2B/B2B2C	407	Surfacing PostHog data to your own customers is an open request, not a shipped capability
#17031	Event retention / scheduled deletion	227	Retention is plan-determined (1 year free, 7 years paid), which matters if policy requires fixed-window deletion
#13160	Feature flag environments	219	Staging and CI flag traffic bills against production quota
#31488	Uptime monitoring	191	Not available natively; budget for a separate tool
#19686	Queryable network API performance metrics	169	Limits using PostHog as the single source for performance data

All six were open when this table was built. Reaction counts and status move; click through before citing.

Where the other PostHog pricing write-ups are wrong

Claim as published	What the vendor page states	Discrepancy
”You don’t have to pay anything for the first 2,500 responses” for Surveys (schematichq.com)	First 1,500 survey responses free (posthog.com/pricing)	1,000 responses overstated in prose; the post’s own adjacent table says 1,500
”The first 2,000 AI credits are free” (schematichq.com)	PostHog AI: 500 free credits (worth $5); Replay Vision: 2,500 credits (worth $25) as a separate allowance (posthog.com/pricing)	Two distinct allowances merged into one wrong number
Logs “First 50 GB Free” (schematichq.com)	First 10 GB free at 14-day retention, plus a separate $0.05/GB 30-day retention line (posthog.com/pricing)	40 GB overstated; the paid retention line omitted
PostHog free tier “tends to only hold for MAUs of <5000” (statsig.com)	1,000,000 free requests/month (posthog.com/pricing)	The post’s own 20-requests-per-MAU assumption implies ~50,000 MAU
Undated rate cards generally	The changelog ships dated changes, such as batch exports now including person_properties by default, which changes Parquet column order for existing object-storage exports and requires manual column additions for warehouse destinations	Any undated pricing summary should be treated as unverified

Corrections are welcome and will be published with a date. If a number here is wrong, send the source URL through this site’s contact route and the row gets fixed.

Frequently Asked Questions

How much do PostHog feature flags cost?

The first 1,000,000 /flags requests each month are free, then $0.0001 per request from 1–2M, $0.000045 from 2–10M, $0.000025 from 10–50M and $0.00001 above 50M, so 5M requests totals $235 (posthog.com/pricing). Experiments bill on the same meter.

How much does PostHog cost in total?

There is no fixed monthly price, because each product meters separately with its own monthly-resetting free tier: events for product analytics, recordings for session replay, requests for feature flags, responses for surveys. Three anchors apply: $0 below all free tiers, usage-based above them, plus optional flat platform packages.

What counts as a billable feature flag request in PostHog?

SDK initialisation, identify(), person property updates, reloadFeatureFlags(), group creation, survey targeting evaluation, and every server-side evaluation call not resolved by local evaluation all bill a request (cutting costs docs). Client-side getFeatureFlag() normally reads cache and does not bill.

Why is my PostHog feature flag bill so high?

Four causes, in order of frequency: local evaluation polling at 10 credits every 30 seconds (864,000 requests monthly per server), forgotten staging or demo environments still polling, client SDKs re-fetching on every pageview or identify(), and Surveys evaluating flags on the same endpoint. Diagnose with the billable usage dashboard.

Is there a PostHog pricing calculator?

Yes. PostHog publishes an interactive estimator on its pricing page and a flag-specific calculator inside its cutting-costs doc, both of which take a monthly request count as input. The hard part is estimating requests, which is exactly what the five architecture cost models above are for.

What is PostHog enterprise pricing?

Enterprise capability is sold as a flat monthly platform package on top of usage-based charges, in three named tiers: Boost, Scale and Enterprise. Take the monthly figure for each from PostHog’s plan comparison table rather than a summary. The top tier adds RBAC, SAML SSO, 60-month activity logs, an 8-hour response target and a dedicated account manager.

What happens when you hit your PostHog feature flag billing limit?

The /flags endpoint returns a quota-limited response, SDKs fall back to defaults (false for isFeatureEnabled(), null for getFeatureFlag()), a quota_limited property appears on the response, and debug mode logs a warning. Your app keeps running, but every flag evaluates to its default, so verify kill-switch defaults are safe.

Is PostHog cheaper than LaunchDarkly or Statsig for feature flags?

It depends on the billing unit. PostHog charges per evaluation request, so cost tracks client chattiness and server polling, while MAU- or seat-based competitors track user and team counts instead. The comparison content ranking for this query is vendor-published. PostHog usually wins for bounded request volume with bundled analytics.

How do PostHog feature flags work with Next.js, and does SSR cost double?

A server-rendered evaluation plus a client-side hydration fetch produces roughly two billable requests per pageview, so 1M pageviews bills 2M requests ($100) and 10M pageviews bills 20M ($710). Bootstrapping flag values into the initial payload halves both figures, to $0 and $460.

Are PostHog feature flags free?

Yes, up to 1,000,000 evaluation requests per month, resetting monthly, with no card required, and the free volume is retained after you upgrade. The free plan is limited to one project with one-year retention, and one always-on server using local evaluation consumes 864,000 of those requests unprompted.

Can I self-host PostHog to avoid feature flag costs?

Yes, a self-hosted edition exists, but the trade is a per-request bill for ClickHouse infrastructure, upgrades and on-call time. GitHub reports the repository licence as NOASSERTION while PostHog describes its open-source product as MIT licensed, so read the LICENSE file yourself before assuming unrestricted use.

How does PostHog compare to Mixpanel?

Mixpanel is an analytics product; PostHog bundles product analytics, session replay, feature flags, experiments and surveys behind separate per-product usage meters. For a flag buyer, the relevant point is that flag rollouts can be measured against events and replays in one account without an integration. See PostHog vs Mixpanel comparison.

Write down one number before you commit to PostHog feature flag pricing: your requests per pageview or per backend request, counted in the network tab. Every dollar figure on this page scales linearly with it, and it is the only input that no rate card, calculator or vendor comparison can supply for you.