Self-hosted InfluxDB stayed cheaper because of per-query pricing

We ran an analytics layer that took over two million writes a day. The data was in InfluxDB, self-hosted on EC2, on an instance with 128 GB of RAM and two terabytes of disk.

We self-hosted because the managed cloud was too expensive, and that was the right call. I was wrong about why, and only found out after we changed the retention policy.

The bill has four meters:

The third one is easy to skim past, and it ends up deciding the comparison. Every query operation is billable, and a dashboard cell is a query. A dashboard with eight cells that refresh every five minutes makes ninety-six billable operations an hour, per viewer.

Storage at $0.002 per GB-hour comes to $1.46 per GB per month. Two terabytes is 2,048 GB, so the disk alone costs $2,990 a month.

Here is the full comparison at the volumes we had, with fifty people using the dashboards:

Self-hosting came out about $2,285 a month cheaper, roughly $27,000 a year. Ingesting two million points a day cost thirty-seven dollars on the managed service, so the writes were never the problem.

We moved raw data to a seven-day window, with a daily rollup written to the relational database, which is what the reports had been reading anyway. Two terabytes became under one gigabyte, and on the managed service the storage line went from $2,990 to $1.31.

The obvious conclusion is that we had been paying for a bad retention policy rather than for a hosting decision, and that the managed service would have been fine if we had fixed the policy first. The bill after the change shows why that conclusion is wrong.

With a gigabyte of data and twenty-three writes a second, you don't need 128 GB of RAM. Sized for that load, self-hosting drops to about $79 a month on a two-vCPU box with 8 GB.

The managed side doesn't drop the same way, because storage was never its only meter:

Self-hosting still wins at every size, but for a different reason. At two terabytes the managed service lost on storage. With storage at a dollar, it loses on query count. That meter grows with the number of people looking at dashboards, and the instance costs the same however many people look.

I thought we self-hosted because we had a lot of data.

In fact we self-hosted because usage-based pricing bills for access, and we were building a product that exists so people can look at their numbers all the time.

That mismatch doesn't depend on data volume. It was there at two terabytes and it is there at one gigabyte. The storage bill was loud enough to hide it, and fixing the storage bill made it visible.

In general, when one meter dominates a usage-based bill, it is telling you about your storage, your traffic or your retention. The quieter meters tell you about your product, and they will still be there after you fix the loud one.

Comparing two invoices compares infrastructure. What you get for the money is a separate question, and availability is the first part of it.

The open-source edition has no clustering, which comes only with the commercial editions or the managed cloud. That sounds as if it settles the argument, but the answer depends on which failures you need to survive.

What we ran was an active-passive pair: two instances sharing one EBS volume, with a load balancer and a heartbeat that failed over when the active node stopped answering. That survives an instance dying, which is the failure you are most likely to see. It does not survive losing the volume or the availability zone, because there was one disk in one zone. The managed cluster survives both.

In practice we bought about 80% of the availability for about 3% of the price, and chose to leave the rest uncovered. Instance failure was the realistic risk, and we covered it. We accepted the risk of losing a zone.

It was a reasonable trade, and I would make it again. The invoice still doesn't show that a trade was made.

Backups, patching and upgrades appear on no invoice, but someone has to do them. We took snapshots and ran upgrades, and neither was hard. They still took someone's time, and that cost only shows up when the person who knows how to do them leaves.

The managed service has SOC 2 and ISO certification, so when a customer's security review asks about the analytics store, you send a document. For your own instance, you answer the questions yourself.

The managed service also comes with a support contract. When something is wrong at 2 a.m. and you don't know why, there is a phone number to call.

With a $2,285 monthly gap, none of that changes the answer. With the $79 gap after the retention change, it nearly does. For seventy-nine dollars a month, a managed cluster with cross-zone redundancy, backups and a support line is a good buy, and we would have taken it if the query meter hadn't been about to grow with our user count.

The arithmetic above is ours. What carries over to other teams is the shape of the workload, so this is how I would decide now.

Take the managed service if

Your read volume is predictable and modest. Query count grows as more people use what you built. If only a handful of internal engineers read your data, that meter stays small and the managed service is cheap.

You keep data for a short window on purpose. At $1.46 per GB-month, storage is expensive for years of history and negligible for a week of it. With a rolling window, the expensive meter stays small.

You need cross-zone redundancy and can't build it yourself. A managed cluster survives the loss of an availability zone, and our pair didn't. If your product goes down when your analytics go down, and you have no one who wants to own a failover pair, buy the managed cluster.

You're under $200 a month either way. At that size the difference is smaller than the time you would spend on it, so take the version with backups and a phone number.

A customer's security review asks about certifications. The managed service can answer with its SOC 2 and ISO documents, and your own instance can't.

Self-host if

Your customers read their own data. Of everything in this list, this is the strongest signal. Per-query billing works directly against a product built around people checking their numbers, and the cost grows as the product grows.

You keep long history and query it rarely. Storage is where the managed bill concentrates, and a disk is eighteen times cheaper than the same gigabytes on the managed service. Years of data with occasional analytical reads is the best case for self-hosting.

Your write volume is high and your read volume isn't. Ingest is nearly free on both: two million points a day cost us thirty-seven dollars on the managed service. If writes dominate and reads are batch jobs, neither platform is expensive, and self-hosting is the cheaper of the two.

You already run infrastructure. If a team already patches instances and tests restores every week, one more instance adds little work. Without such a team, self-hosting creates a new job, and you are no longer saving money.

Leave when the largest meter can't shrink

If your bill is dominated by a meter you can't reduce, leave. We could reduce storage, and we did. We couldn't reduce query count, because query count was customers using the product, and reducing it would have meant making the product worse.

That is the test I would use on any usage-based service: look at the largest meter and ask whether you could halve it without harming what you sell. If you can, fix it and stay. If you can't, the vendor's pricing model and your business model pull against each other, and the gap widens every month the product grows.

At twenty users on live dashboards, the two options differ by eight dollars a month, which is noise. The tables above can't show the threshold that matters: the point where the monthly difference becomes larger than the attention it takes to run the database yourself.

At two terabytes we were well past that point. After the retention change we weren't, and we stayed only because we expected the user count, and with it the query meter, to keep climbing.

I would look at the meter breakdown before choosing an architecture. We took the total, saw it was too high, and moved. That worked, but it meant we spent two years unable to say which of four things we were paying for.

I would also fix retention first, whatever the hosting decision. It was the cheaper change by an order of magnitude and would have helped on either platform, and we made it second.

And I would price what we were giving up along with what we were paying. I ran the numbers on two invoices and called it a comparison, when one column included cross-zone redundancy and the other stopped at the instance. Both columns were defensible, but what the cheaper one left out was never written down.

Figures are US East list rates as of mid-2026. Self-hosted totals include the instance, EBS, snapshots, backup, cross-AZ transfer and CloudWatch. They leave out maintenance, upgrades and on-call time, which appear on no invoice, and the standby instance, which adds roughly the instance line again. Point size and query volume are estimates from our own usage, not measurements published by the vendor.