Cost Model
HatiData charges for what actually executes — measured per query, not per hour. Compute suspends automatically after 5 seconds of inactivity, so an agent that issues one query per minute pays for seconds, not minutes. Each query's cost is computed from a credit weight formula that accounts for the query's complexity and result size.
Credit-Based Billing
HatiData uses a credit system rather than raw compute units. Credits are a stable, predictable abstraction over the variable cost of query execution — a simple lookup query against a small table costs 1 credit; a full-table scan across multiple large tables costs significantly more.
Credits are calculated during the Query Pipeline in two passes:
- Estimate (step 4): Before execution, the pipeline projects the credit cost using table statistics. This is used for quota checks.
- Actual (step 12): After execution, the actual cost is computed using real row counts and recorded to the metering store.
The actual cost is always what appears in billing and quota deductions. If the actual cost is lower than the estimate, the difference is not charged. If the actual cost exceeds the estimate (rare, typically caused by statistical anomalies in cost projection), the excess is charged.
Credit Weight Formula
| Factor | Weight |
|---|---|
| Base query (any SQL statement) | 1.0 |
| Each additional table referenced beyond the first | +0.5 per table |
| Full table scan (no selective WHERE predicate on indexed column) | +2.0 |
SELECT * (wildcard column selection) | +1.0 |
| Result set size exceeding 10,000 rows | +1.0 per additional 10,000 rows |
Examples:
-- Simple lookup: 1 table, indexed WHERE, 50 rows → 1.0 credit
SELECT * FROM users WHERE user_id = 'abc123'
-- Analytics query: 3 tables, aggregation, 0 rows returned → 1.0 + 0.5 + 0.5 = 2.0 credits
SELECT department, COUNT(*) FROM employees e
JOIN departments d ON e.dept_id = d.id
JOIN locations l ON d.location_id = l.id
GROUP BY department
-- Full scan: 1 table, no WHERE, SELECT *, 250,000 rows → 1.0 + 2.0 + 1.0 + 25×1.0 = 29.0 credits
SELECT * FROM events
Why This Formula
The formula penalizes the two most resource-intensive patterns: full table scans (which read every page of a table) and large result sets (which consume memory for sorting, serialization, and transmission). Both patterns are common in agent workloads — agents that retrieve large result sets to process in-memory on the agent side should instead push that processing into SQL, where it executes against columnar storage orders of magnitude faster.
The per-table weight encourages agents to fetch only the tables they need. Agents that JOIN 5 tables to retrieve one column from each should consider whether a narrower query with a subquery or CTE would serve them better.
Per-Second Billing
Compute time in HatiData is measured in seconds of active execution, not in server-hours. Billing starts when a query begins execution and stops when results are serialized.
Compute seconds are converted to a dollar amount based on the organization's pricing tier. The credit formula above determines how many credits a query consumes; the tier pricing determines the dollar value per credit.
5-Second Auto-Suspend
After the last query in a session completes, HatiData begins a 5-second countdown. If no new query arrives within those 5 seconds, the compute session suspends. The engine state is serialized to the local SSD cache and the active memory footprint is released.
When the next query arrives (even seconds later), the session resumes from the local SSD cache — engine state is restored in milliseconds, and the query runs without the agent perceiving a cold-start delay for cached data.
This auto-suspend behavior means agents that query intermittently — for example, a monitoring agent that checks a metric table once per minute — pay for 5 seconds of compute per query rather than 60 seconds per minute.
The auto-suspend timer is configurable (HATIDATA_AUTO_SUSPEND_SECONDS, minimum: 5, maximum: 3600). Organizations with high-frequency agent workloads may want to increase this value to avoid the minor overhead of repeated suspend/resume cycles. Organizations with infrequent workloads benefit from keeping it at the default 5 seconds.
Per-Agent Metering
Credits are tracked at the agent level, not just the organization level. Every query is associated with the agent_id claim from the agent's JWT or API key. This means the control plane dashboard shows a per-agent breakdown of credit consumption:
Organization: acme-corp (2,847 credits used this month)
├── analytics-bot 1,203 credits (42%)
├── nightly-report 891 credits (31%)
├── compliance-scanner 612 credits (21%)
└── ad-hoc-queries 141 credits (5%)
Per-agent metering serves two purposes:
- Accountability: Teams can see which agents are consuming the most resources and optimize accordingly.
- Per-agent quotas: Organizations can set individual credit limits per agent, preventing a single runaway agent from exhausting the organization's monthly allocation.
Per-Agent Quota Limits
Quota limits can be configured at two levels:
| Level | Configured in | Enforced at |
|---|---|---|
| Per-agent monthly limit | Control plane dashboard or API | Pipeline step 5 (before execution) |
| Per-org monthly limit | Subscription tier + manual override | Pipeline step 5 (before execution) |
When a query would exceed either limit, it is rejected before execution with a quota_exceeded error. The error response includes the estimated cost of the rejected query, the agent's remaining balance, and the reset date for the current billing period.
Agents can query their own quota status programmatically:
-- HatiData system view: agent's current quota state
SELECT * FROM _hatidata_quota_status
-- Returns: credits_used, credits_limit, credits_remaining, reset_date, agent_id
Pricing Tiers
HatiData offers four tiers. All tiers use the same credit formula — the tier determines the monthly credit allocation, feature access, and SLA.
| Tier | Price | Monthly credits | Audit retention | SLA | Per-agent metering |
|---|---|---|---|---|---|
| Free | Free | 1,000 | 7 days | — | Yes |
| Cloud | $29 / month | 10,000 | 90 days | 99.5% | Yes |
| Growth | $199 / month | 100,000 | 1 year | 99.9% | Yes + API |
| Enterprise | Custom | Custom | 7 years | 99.99% | Yes + API |
Free Tier
Free tier runs on HatiData's managed infrastructure with limited capacity. There is no billing, but a 1,000-credit monthly limit applies. Credits are computed and metered — this allows teams to evaluate HatiData before upgrading. Free tier includes 1 environment, 3 users, and 10 GB storage.
Cloud Tier
Cloud tier includes 10,000 credits per month, 5 environments, 25 users, and 500 GB storage. This is enough for approximately:
- 10,000 simple lookup queries, or
- 5,000 single-table analytics queries, or
- ~350 full-table scans against medium-sized tables (250K rows)
Additional credits beyond the monthly allocation are billed at the overage rate for the organization's region. Overage is charged at the end of the billing period; mid-period, queries that would cause overage are permitted up to a configurable overage ceiling (default: 110% of monthly allocation).
Growth Tier
Growth tier includes 100,000 credits per month, 20 environments, 100 users, and 5 TB storage. Growth adds:
- 1-year audit log retention
- 99.9% availability SLA
- Up to 500 concurrent queries
- Up to 10,000,000 rows per query
- Programmatic metering API access
Enterprise Tier
Enterprise pricing is negotiated per organization based on expected query volume, data volume, and deployment topology. Enterprise contracts include:
- Custom monthly credit allocation with reserved capacity guarantees
- 7-year audit retention for regulatory compliance
- 99.99% availability SLA with defined response/resolution times
- Volume discounts for high-credit-consumption workloads
- Dedicated compute (no shared tenancy on the control plane)
- Custom auto-suspend and resume SLA for time-sensitive agent workloads
Local Mode
For development and testing, HatiData can also run entirely on your machine via hati dev. Local mode has no billing, no credit limit, and no connectivity requirement. Credits are still computed and metered locally — this allows teams to anticipate costs before moving to a paid tier. See Deployment Modes for setup.
Monitoring Credit Usage
Dashboard
The control plane dashboard (app.hatidata.com) shows real-time credit consumption broken down by agent, query type, and time period. Usage graphs update on a 60-second refresh cycle.
API
Credit usage is available programmatically through the control plane API:
GET /v1/metering/usage?period=current&group_by=agent_id
Authorization: Bearer <token>
{
"period": "2026-02",
"total_credits_used": 2847,
"total_credits_limit": 50000,
"breakdown": [
{ "agent_id": "analytics-bot", "credits_used": 1203 },
{ "agent_id": "nightly-report", "credits_used": 891 }
]
}
Alerts
Credit usage alerts can be configured in the dashboard to notify when an agent or the organization reaches a specified percentage of its monthly allocation (default alerts at 75% and 95%).
Cost Optimization Tips
Avoid SELECT *: Selecting all columns costs +1.0 credit and transmits unnecessary data. Select only the columns the agent will use.
Add WHERE predicates to large tables: Full-table scans cost +2.0 credits. Even a weak predicate (e.g., WHERE created_at > '2025-01-01') that reduces the scan by 30% saves the full-scan penalty.
Use CTEs to pre-filter: Push filtering into CTEs rather than JOINing large tables and filtering in the outer query. The query optimizer handles CTEs well and the cost estimator will recognize the reduced table footprint.
Batch agent queries: An agent that issues 10 queries of 1 credit each costs 10 credits. A single aggregated query that returns the same information costs 1–3 credits. Design agent prompts to retrieve data in fewer, broader queries.
Set per-agent limits: Use per-agent quota limits to catch runaway agents early — before they consume a significant portion of the organization's monthly allocation.
Related Concepts
- Query Pipeline — Steps 4, 5, and 12 where cost estimation, quota checking, and metering occur
- Two-Plane Model — How metering data flows from the data plane to the control plane
- Control Plane API — Programmatic access to usage metrics and quota management