Why high-volume usage billing becomes an infrastructure decision
When usage events grow faster than invoices, the billing question stops being about plans and becomes a question about where metering runs. Lago is the main self-hosted option for metering and invoicing, but it needs a separate payment processor and its own operations. That split is the starting point for this decision. Lago calculates what to charge and when, then hands the charge to a gateway such as Stripe, Adyen or GoCardless, so keeping Stripe for payments is a normal configuration rather than a workaround. Stripe Billing remains a capable product for many teams, and the question here is whether your event volume, data rules and staffing make a self-hosted pipeline the better fit.
Three points decide it. The first is event volume: the number of usage events per day, their peak rate and how long you must keep them determine whether Lago's default Postgres-backed storage is enough or whether the optional ClickHouse store is needed. The second is data location: usage events often contain customer identifiers and product activity that some regulators and customer contracts restrict to particular regions or systems. The third is who runs the pipeline: someone must own upgrades, queue health, worker scaling, backups and invoice reruns after an incident. Ask your team to write down expected events per month, retention periods and the on-call owner before comparing options.
The rest of this page works through those three points in order. Each one turns into a concrete cost and staffing question, so the sections that follow state which components you pay for, what recurs and what to request in a written scope. Confirm the current Lago release and its supported payment integrations with the project before you plan a pilot, since the self-hosting guidance recommends pinning a tagged version rather than the latest image.
What high-volume metering requires from the billing stack
A high-volume usage product puts five demands on its billing stack before any pricing is configured. Each one depends on your own event volumes, retention rules and data classification, so treat the points below as questions to answer with numbers from your environment.
Sustained event ingestion
Usage events arrive continuously from your API gateway, model servers or application services, and bursts can be far larger than the average. Lago receives events through its API, and its API and worker processes can be scaled separately. Confirm your peak and sustained events per second, the acceptable delay before an event is counted, and whether duplicate events from retries must be deduplicated by a transaction ID.
Raw event storage
Aggregated counts hide the evidence behind a disputed invoice, so most teams keep raw usage events for a defined period. PostgreSQL holds Lago's application data by default, and ClickHouse is an optional external store for high-volume events that is disabled by default. Decide where raw events live, how long they are kept, and who can query them before you size the database.
Rating and aggregation into invoices
Rating converts raw events into billable quantities under your plan rules, including tiers, minimums, included allowances and proration. Errors here reach customers directly as wrong invoices. Confirm which pricing models you need, how late or out-of-order events are handled at period close, and how you will reconcile rated totals against your own usage logs each billing cycle.
Separation of billing and card data
Billing needs customer identifiers, plan and invoice data. Card numbers belong in a payment processor or vault certified to PCI DSS Level 1. Lago does not store card data itself and needs a separate payment processor such as Stripe, Adyen or GoCardless to collect payment. Map which systems can see card tokens, and confirm that no billing database field or log line carries card details.
Operational ownership of the metering pipeline
Once metering is self-hosted, your team owns uptime, upgrades, database backups, queue health and rollback. Lago's self-hosting docs recommend pinning the last tagged release rather than the latest image, so every upgrade becomes a planned change. Confirm who is on call for billing incidents, how often you will upgrade, and what your recovery time is if the clock or worker process stops.
What Stripe Billing includes for metering and when teams look at Metronome
Stripe Billing includes usage metering through its Meters API, so a team that already uses Stripe for subscriptions can record usage events and attach them to prices without adding a separate metering product. For many API and AI products, that built-in path is enough. The decision starts with an inventory of your own usage model: how many event types you send, how many customers and subscriptions consume them, how often you need to reprice or recompute usage, and whether usage must be reconciled against your own logs before an invoice is issued. Write those numbers down before you compare platforms, because they determine which limits matter.
Teams with very large or complex usage models often compare Stripe's metering with a dedicated metering vendor such as Metronome. Typical reasons include custom aggregation logic, commit and credit drawdown structures, high cardinality dimensions, and a need to keep usage data in a specific location. This page does not supply Stripe or Metronome event limits, retention periods, pricing structures or data locations, so confirm each of these directly with the current documentation and sales teams of both vendors before you decide. Ask for the figures in writing, for your expected event volume and retention period, rather than relying on general statements.
Whichever metering layer you choose, payment processing stays with a payment processor. Stripe Billing, Metronome and a self-hosted billing engine all hand card authorization and settlement to a processor, so the question you are answering is who calculates usage and invoices, not who moves the money. Document which system is the source of truth for usage, how invoices reference payment intents, and how a failed charge is retried. A clear ownership map for usage events is the single most useful artifact to prepare before any migration or vendor evaluation.
Which options fit high-volume metering and how they meet the constraint
This table compares where usage events are stored and how each option meets the data control constraint for high-volume metering. Read the second column first, then check the last column against your contracts and your own sizing. Lago needs a separate payment gateway such as Stripe, Adyen or GoCardless, and Kill Bill is covered on its own sibling page.
| Option | Where event data sits | How it meets the constraint | Trade-offs and what to confirm |
|---|---|---|---|
| Stripe Billing Meters | Stripe's hosted infrastructure | Metering stays inside the same vendor that processes payments, with no extra system for you to run | Usage data and billing logic sit with Stripe, and fees scale with billing volume. Confirm where meter events are stored, retention periods and the region options in your agreement. |
| Metronome | Metronome's hosted platform | A dedicated metering and usage billing vendor separate from your payment processor | Adds another processor of usage data and another contract to manage. Confirm data location terms, subprocessors, retention and export rights before shortlisting. |
| Self-hosted Lago, PostgreSQL storage | Your PostgreSQL database in your own infrastructure, as deployed by Lago's Docker Compose setup | Events, usage and invoices stay in a database you control, with Redis and workers in the same environment | You operate the API, workers, Redis, PostgreSQL and PDF generation. Lago's FAQ says a separate payment gateway is needed, so decide whether Stripe stays as processor. |
| Self-hosted Lago with optional ClickHouse | A ClickHouse store you operate for high-volume events, which is disabled by default | Keeps very large event volumes in a dedicated analytical store while billing data stays in your environment | Adds a ClickHouse cluster to size, back up, monitor and upgrade. Confirm the sizing guidance for your event volume with Lago's documentation and your own load tests. |
How Lago's event pipeline and optional ClickHouse store fit together
Lago's self-hosted Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. Usage events enter through the API, and the workers process them: the API worker handles asynchronous jobs such as aggregating usage and generating invoices, while the clock worker runs scheduled work such as period-end billing. Redis carries the job queue between them, and PostgreSQL holds the application data, including the metering state that feeds charges. Gotenberg renders invoice PDFs. Before you size anything, map each of these components to a team that owns its uptime, backups and upgrades.
ClickHouse is an optional external store for high-volume events, and it is disabled by default. That default matters for an API or AI product: the standard deployment keeps events in PostgreSQL, which may be enough at low volume but is the first thing to test under your own load. If your event rate is high, you must enable ClickHouse deliberately, provision it as a separate system with its own storage, backup and monitoring, and size it against your measured event volume and retention period. Confirm the configuration keys and supported ClickHouse versions in the self-hosted documentation for the release you pin, since the setup is not a simple toggle.
Lago is licensed under AGPLv3, so if you modify the platform and make it available to users over a network, you must review your obligations with counsel before you deploy. The product calculates what to charge and when, produces invoices and sends the charge to a payment gateway for collection. It does not hold the card relationship itself, so you still need a processor such as Stripe, Adyen or GoCardless, and that integration belongs in your load test and failure-mode plan. Decide early which team owns the gateway credentials and how a failed collection is retried, because billing errors often surface there rather than in metering.
How to deploy Lago for metering in your own infrastructure
This sequence takes a team from sizing its event volumes to a pinned, tested Lago deployment that meters usage in its own environment while a payment gateway collects the money.
Confirm event volumes and retention needs
The platform or finance lead, with the engineering owner of the usage events, writes down the expected event rate at normal and peak load, the number of billable metrics, and how long raw events must be kept for disputes, audits and re-rating. Those figures decide whether PostgreSQL alone is enough or whether ClickHouse belongs in the design. Done means a signed-off sheet with peak events per second, daily event totals, retention periods and the named owner of each metric. Ask your vendor or implementer to confirm the sizing assumptions in writing before any hardware or cloud spend is committed.
Choose the deployment target
The infrastructure team selects where Lago runs: a single virtual machine for evaluation, a Kubernetes cluster for production, or a dedicated environment in a data center or air-gapped network. The choice depends on existing platform standards, backup tooling and the region that the data residency rules require. Done means a documented target with named owners for compute, PostgreSQL, Redis, network ingress and object or PDF storage, plus a decision on who operates each component after go-live.
Pin the last tagged release
The engineer who owns the deployment sets the image version to the last tagged release listed in the Lago releases on GitHub, not the latest image tag. Lago's self-hosting documentation recommends this practice. The change is recorded in version control so that every environment runs the same build. Done means the pinned tag appears in the deployment manifest and the team can state which version each environment uses. Upgrades then become deliberate decisions rather than surprises at pull time.
Run the Docker Compose stack for evaluation
The platform engineer starts the self-hosted Docker Compose stack in a non-production environment. It brings up the front end, the API, the API worker, the clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. The engineer creates a test organization, defines a billable metric and sends sample events. Done means invoices render correctly, the workers process jobs without backlog, and the team has written down the resource use observed under test load. ClickHouse stays disabled at this stage because it is optional and off by default.
Move larger deployments to Helm with dedicated workers
For production volumes, the platform team moves from Compose to the Helm charts that Lago's documentation points larger deployments toward. It separates API, worker and clock components, sizes Redis and PostgreSQL for the expected load, and configures dedicated workers so that event processing does not compete with invoice generation. Done means the chart values are stored in version control, each component has resource limits and health checks, and the team has a runbook covering restarts, scaling and database backups.
Decide on ClickHouse and test peak ingestion
The data and platform engineers decide whether to enable ClickHouse as the external event store, using the sizing from the first step. They run a load test at the expected peak event rate, plus a margin they agree on, and measure ingestion lag, query time for aggregations used in invoices, and storage growth over the retention period. Done means a recorded test report with the configuration tested, the results, and a clear answer on whether the default setup meets the requirement. If it does not, the team changes the design before any customer is billed from it.
Configure the payment gateway integration
The billing operations lead connects Lago to the payment gateway that will collect funds, such as Stripe, Adyen or GoCardless, as listed in Lago's README. Lago calculates what to charge and when, then sends the charge to the gateway, so the gateway credentials, webhook endpoints and retry rules must be set and tested in a sandbox first. Done means a test subscription produces a successful payment, a failed payment is handled as designed, and webhooks reach Lago. Ask the gateway provider to confirm its current webhook and API requirements, because these change independently of Lago.
Plan upgrades against each GitHub release
The platform owner sets a recurring review of the Lago releases on GitHub and reads the release notes for every version between the pinned tag and the target. Recent releases illustrate why this matters: v1.54.0 was released on October 6, 2026, and v1.55.0 followed on October 7, 2026, so an upgrade from v1.54.0 requires reading the notes for v1.55.0 separately. Done means a written upgrade procedure with a staging test, a database backup taken before migration, a rollback plan, and an approval record for each version moved into production.
Evidence finance and audit teams ask for from usage metering
Finance and audit teams rarely ask whether metering works. They ask whether they can reproduce a past invoice from stored events and show who changed what. The cards below list the records that let a team answer those questions with self-hosted Lago. DeployOpen prepares these controls and evidence for assessments, but independent auditors issue any report.
Raw usage event records
Keep every usage event as received, with the event's own timestamp and the time your pipeline ingested it. Lago's event pipeline can route high-volume events to optional ClickHouse storage, so confirm where events land, how long they are retained and whether late or duplicate events are recorded rather than silently dropped. Finance teams need this to explain a billed quantity that differs from the application's own counters. Ask for the ingestion log before the first invoice run.
Aggregation logic per billing period
Record the metric definition, the aggregation type (such as sum, count or maximum) and the window used for each billable metric, along with the version of that definition in force during each billing period. A change to how a metric aggregates changes past totals if it is applied retroactively. Store the definitions in version control next to the pricing configuration so that a reviewer can recalculate any invoice from the raw events.
Invoice history and changes
Retain every generated invoice, every credit note and every manual adjustment with the user who made it and the reason. Lago calculates charges and passes payment collection to a gateway such as Stripe, so the invoice record in Lago and the payment record at the processor must reconcile. Check that a regenerated or voided invoice keeps its original number and that the audit trail shows both versions.
Access logs for billing data
Collect authentication events, role assignments and API key creation for the Lago application, plus database access to the PostgreSQL store that holds customer and invoice data. Auditors typically sample these logs to test whether only authorized staff could change prices or issue credits. Confirm that logs are shipped off the billing hosts, so an administrator cannot edit them, and that API keys are scoped and rotated on a documented schedule.
Backup and restore test records
A backup only counts as evidence once a restore has been performed and recorded. Test restoring the PostgreSQL database and, if ClickHouse is enabled, the event store into a separate environment, then compare recalculated invoice totals with the originals. Log the date, the restored point in time, the people involved and the discrepancies found. Ask your team how long backups are kept and who can delete them.
Change record for pinned versions
Lago's self-hosting guidance recommends pinning the last tagged release rather than the latest image, so every upgrade is a deliberate change. Record the version running in each environment, the release notes reviewed, the test results and the approver for each move. Lago's GitHub releases list dated tags, which gives you a reference point for each upgrade decision. Keep this record alongside the configuration repository.
What running metering yourself costs to operate
Running Lago yourself means paying for the infrastructure it needs, and the largest cost driver is usually how many events you send and how long you keep them. The self-hosted Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. Each of these is compute and storage you provision and pay for in your own cloud account or data center. ClickHouse is optional and disabled by default, but a high-volume usage product will likely need it, so a ClickHouse cluster becomes a separate line item with its own sizing, replication and backup. Ask your implementation partner for a written sizing based on your peak event rate, event retention window and number of meters, and confirm which of these components you will run in high availability.
The software license is not the main recurring cost. The open-source edition of Lago is free and includes fundamental billing features, while Enterprise plans add premium features. Confirm with Lago which premium features your pricing model actually needs, because an Enterprise license is a separate contract that recurs. Staff time is the cost most teams underestimate: someone must apply upgrades, pin and test each tagged release (the self-hosting docs recommend pinning the last tagged version rather than the latest image), staff an on-call rota for the workers and queues, and reconcile metered events against invoices every billing cycle. Invoicing frequency and the number of customers multiply that reconciliation work.
The one-time cost is the migration itself: mapping existing Stripe subscriptions, meters and prices into Lago, validating a parallel run of invoice totals, and cutting over without double charges. Invoicing frequency, the number of meters and the complexity of pricing rules all push this effort up. Ask for a fixed-scope proposal that lists deliverables, a parallel-run period, the reconciliation method you will sign off on, and a separate line for the ongoing support or retainer you expect after go-live, so you can compare the total against your current per-volume billing fees.
Questions teams ask before running high-volume metering in-house
What does running usage metering in-house cost, and what drives it up?
The cost has two parts: a one-time build and migration effort, and recurring infrastructure and operations. Lago's software license is free under AGPLv3 for the community edition, but Enterprise plans add premium features and carry their own fees, so ask the vendor for the exact terms that apply to you. The main cost drivers are event volume, which sets the size of the database, queue and worker fleet; the number of pricing models you run; the number of downstream systems that must receive invoices; and how many environments you maintain. Volume matters most for usage-based products, because every API call or model token becomes a stored event that must be deduplicated, aggregated and retained. Ask any provider for a quote that separates license, infrastructure, migration, integration and support so you can compare each line with the cost of your current billing fees.
How long does a self-hosted metering deployment take?
The timeline depends on the amount of work you bring in, not on a fixed number. The steps that usually set the pace are agreeing the meter definitions and pricing rules, mapping existing Stripe customers and subscriptions, building the event ingestion path from your product, validating invoices against finance's expected totals, and completing security review of the hosting environment. Parallel running is often the longest step, because you need enough billing cycles to confirm that usage totals match before switching invoice generation. Teams with a clean product event schema and few pricing variants move faster than teams with legacy plan logic. Under a fixed-scope engagement, DeployOpen agrees the scope, deliverables and timeline in writing before work starts, so the schedule reflects the agreed inputs rather than an estimate made in advance.
Can our own team run Lago without outside help?
A capable platform team can deploy Lago with the Docker Compose or Helm approach described in the vendor documentation, but the harder work is usually the billing logic and the surrounding controls. Plan for ownership of several components: the application, PostgreSQL for application data, Redis as the job queue, the workers that run clock and billing jobs, and Gotenberg for PDF generation. Each needs patching, backup, monitoring and capacity planning. The answer depends on whether you have engineers who can own the event pipeline during peak traffic, and finance staff who can review invoice logic before each release. If those skills are thin, a fixed-scope implementation or a retainer for upgrades and support can cover the gap while your team builds the knowledge.
What do our engineers and finance staff need to provide?
Engineers need to provide a stable event schema, a way to send usage events reliably with unique identifiers so duplicates can be discarded, and access to the staging and production environments where Lago will run. They also need to own the metric definitions, such as how tokens, requests or compute seconds are counted, because a wrong definition produces wrong invoices. Finance staff need to define pricing rules, tax handling, credit notes, dunning steps and the revenue reports they depend on, and to approve test invoices during parallel running. Both groups should agree on a reconciliation method before go-live, comparing usage totals and invoice amounts between Stripe and the new system. Without that shared sign-off, a technically sound deployment can still produce billing disputes.
Can Lago replace Stripe as our payment processor?
No. Lago calculates what to charge and when, but it does not move money itself. Its documentation states that businesses need a separate payment processor, and the README names Stripe, Adyen and GoCardless as supported providers. In practice, this means you keep a payment gateway for card acceptance, tokenization and settlement, and Lago sends the charge instructions to it. This is the central reason the migration can keep Stripe for payments while moving billing logic out. Confirm with your gateway how card data is stored and whether existing payment methods can be linked to the new billing system, because that determines whether customers must re-enter card details.
Does ClickHouse improve Lago, and when should we skip it?
ClickHouse is an optional external store for high-volume events in Lago, and it is disabled by default. Add it when event volume grows large enough that the default storage path becomes the bottleneck for aggregation and reporting, which you can test with your own load profile before committing. Skip it when your volume is moderate, when your team has no operational experience with a columnar database, or when you do not need fast queries over raw events. Adding ClickHouse introduces another stateful system to back up, secure, upgrade and monitor, so the cost is operational as well as infrastructural. Ask for a load test against your expected peak event rate and retention period before deciding, and treat the result as the input to the architecture decision.
How DeployOpen deploys Lago for high-volume metering
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For high-volume usage billing, that means scoping the event pipeline, storage and billing workload in writing before any build starts, then handing over documented operations you can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Scope maps your event volumes, billable metrics, plans and payment processor to the Lago components you need
- Sizing covers whether ClickHouse is needed as an external event store, which is disabled by default in Lago
- Scope states who owns the Stripe integration, invoice generation cutover and reconciliation checks
How we build
- Deploy Lago with Docker Compose for evaluation, or Helm charts and dedicated workers for larger deployments
- Pin the last tagged release rather than the latest image tag, and record the chosen version in configuration
- Test event ingestion, metering accuracy, invoice output and PDF generation against representative usage data
- Harden the PostgreSQL, Redis and worker tiers, and document backup and restore for each component
How we hand over
- Deliver runbooks for upgrades, worker scaling, queue monitoring and incident response
- Document metric definitions, plan configuration and the procedure for changing billable metrics
- Provide evidence and configuration records that your auditors or compliance team can review
- Walk your operations and finance teams through invoice checks before the cutover date is confirmed
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover tracking new Lago releases, testing upgrades in a non-production environment first
- Support can include periodic security testing of the billing APIs and the event ingestion endpoints
- Ask for a written quote from the agreed scope, since DeployOpen does not publish a price list
