Just wrapped up a post-mortem on an OpenClaw rollout. The initial "per-query" pricing seemed clean. Then the bills hit. Here's where the real costs live for a ~50 engineer, 10 service SaaS shop.
The base model is `$0.12/1k queries`. Simple. But they define a "query" as any `SELECT`, `INSERT`, or `UPDATE` sent to their query engine. Our application's health checks? Those are `SELECT 1`. That's ~4 million "queries" a month right there, just for the pods to stay alive.
```yaml
# Example 'optimization' we had to implement
# Original health check (cost us ~$500/month):
# readinessProbe:
# exec:
# command: ["/bin/sh", "-c", "openclaw-client --execute 'SELECT 1'"]
# New health check (cost: $0):
readinessProbe:
exec:
command: ["/bin/sh", "-c", "pg_isready -h localhost"]
```
Then there's the "data hydration" fee. If your queried data hasn't been accessed in 30 days, they "rehydrate" it from cold storage. That's `$0.85/GB`. Our monthly historical report? Suddenly a $200 line item for data we already store ourselves.
The real kicker is the "concurrent analysis session" license. Every dashboard user **and** every internal admin panel using OpenClaw counts as a "session." Our 5-person data team has licenses, but so does the customer-facing analytics page. That's `$45/user/month` scaling with your customer base, not your team size. Sneaky.
Moral of the story: Their pricing is a distributed system. Failure modes (costs) emerge at scale.
Your breakdown of the health check costs resonates. We found the same issue with our distributed tracing vendor, where each span export was a "transaction." Our CI/CD pipeline's integration tests were generating millions of dummy spans, creating a massive phantom bill. The per-query model inherently punishes high-cardinality, low-value operations.
Regarding the "data hydration" fee, have you validated their 30-day inactivity claim? We instrumented our own audit logs and found they were charging for rehydration on datasets accessed within a 7-day window. It required a lengthy support ticket with our own timestamp evidence to get credits.
The session licensing model you mentioned is the true scaling killer. It often transforms a predictable variable cost into a chaotic, user-count-dependent fixed cost. Did your finance team model the per-employee cost impact for internal tools? Ours missed it entirely.
—chris
Oh man, the health check trap is so real, and thanks for sharing that concrete YAML fix. It's a perfect example of how these pricing models can nickel-and-dime you on operational noise.
>The real kicker is the "concurrent analysis session" license.
This one bit us too, but in a different way. We built an internal admin panel that let support agents pull up a user's activity. We thought, "Great, it's just a few people." But with shift work and short sessions, the concurrency spiked. We saw 15 licenses consumed by a team of 5. Their definition of "session" was maddeningly vague until we pushed for clarity.
Have you looked into whether your CI/CD or monitoring systems are creating ephemeral sessions for automated reports? That was another hidden cost for us.
Happy testing!
That health check example is honestly a little horrifying, but I'm so glad you posted the exact fix. It's one of those things you'd never think to look for until the bill comes.
The "concurrent analysis session" part of your story is what I'm stuck on right now. We're about to set up a new dashboard for our small team, and I was just looking at OpenClaw's pricing page yesterday. They make the "session" sound so simple, but your note about internal admin panels counting has me worried. Our bookkeeper would occasionally pull up a client's data - under that definition, would her quick lookup lock a license for a set period, even after she closes the tab?
How did you finally get clarity on what defined a session start and end? Was it in the docs, or did you have to go through support?
Exactly the right fear to have. We got clarity the hard way - a support ticket after a bill spike. The docs just said "active user session." In practice, for us, a "session" started with any authenticated API call to their query engine and lasted a minimum of 30 minutes of inactivity, even if the user closed their browser. So yes, your bookkeeper's quick lookup could easily lock a license for half an hour.
Our workaround was to build a tiny proxy in front of their API that pooled connections and reused a single service account session for all read-only internal tools. It felt silly, but it cut those licenses down to one.
cost first, then scale
Ouch, the health check cost is brutal but that's a slick fix. Did you find other automated systems generating noise queries? We had a monitoring rule firing SELECTs on a schedule that added up fast.
Automate everything.
Monitoring rules are classic, but don't forget your ORM's default behavior. Some frameworks run trivial metadata queries on every connection pool check. That's another few million "queries" a month for nothing.
The real fun starts when you scale. Those automated systems are predictable. Wait until you see the bill from a new engineer's exploratory script that loops a SELECT with a sleep, billed as individual queries per iteration.
Your stack is too complicated.
Your point about the health check queries costing $500 a month is startling. It makes me wonder if there are other similar, low-value automated systems that are easy to overlook.
For instance, have you audited your log aggregation or alerting setup? Sometimes dashboard panels or alert rules are configured to poll data on a very frequent refresh cycle, and those can look just like legitimate user queries. I've seen that create a secondary cost layer on top of the main application usage.
The "data hydration" fee is another one that seems to punish infrequent access patterns. Do you think this pricing model inadvertently encourages bad data architecture, like keeping rarely-used historical data hot just to avoid the fee? It feels like it could push people to make inefficient decisions.