Pricing · Tables

Tables credit pricing

Tables pricing on KERNSTACK has one line of its own — storage at 0.04 credits per GB-hour — and borrows the compute line for access: the function or worker doing the read pays its own GiB-seconds. This page works the storage arithmetic across dataset sizes and contrasts it with per-request-unit database pricing.

How Tables is metered on one credit balance

Base Rate Summary: Table storage is 0.04 credits per GB-hour — about 29 credits per GB-month. Reads and writes ride on the compute of the functions and workers performing them (0.01 credits per GiB-second).

The storage line, worked

A gigabyte held for a 730-hour month costs 730 × 0.04 ≈ 29 credits. Ten gigabytes ≈ 292 credits; a terabyte ≈ 29,200. Indexes declared on the table (secondary key indexes) store with the table family and follow the same rate — there is no separate “index SKU”, and seed files or audit history you keep are just more gigabytes at the same visible price.

Access is compute, not units

There are no read or write capacity units to provision or decipher. A keyed read inside a function costs the function’s execution time; a worker scanning a million rows for a nightly job pays for its runtime at 0.01 credits per GiB-second. Spiky products therefore cannot be throttled by a capacity guess made in January, and quiet ones pay for their quiet.

  • No provisioned throughput to buy, no on-demand per-unit price list to decode
  • Change streams invoke your function with batched changes — the function’s seconds are the charge
  • Exports for auditors or analytics read the same tables; the export job is ordinary worker compute

Credit Consumption Scenarios vs Hyperscaler Billing

Workload Scenario Monthly Resource Footprint KERNSTACK Credits Hyperscaler / SaaS Equivalent
Light Side-project dataset: 1 GB held all month, light keyed traffic ≈30 credits storage + incidental compute Storage plus per-read/write units; the free tier hides the shape until it does not
Steady Product dataset: 50 GB, millions of keyed reads in functions ≈1,460 credits storage + function compute On-demand units make every read a micro-charge; provisioned capacity makes it a capacity-planning job
Heavy Event/audit history: 1 TB retained, batch workers scanning nightly ≈29,200 credits storage + worker compute Storage, units, and archival tiers itemised separately; retrieval from cold tiers priced again

Frequently asked questions

Correct. Access spends the compute of whoever performs it. A read-heavy function shows up as function seconds, a scan-heavy worker as worker seconds — one meter, attributed to the code that caused it.

Its storage, at the same 0.04 credits per GB-hour as the table’s. Declaring an index is a stack.json decision with a storage consequence, not a new product subscription.

Linearly and visibly: every retained gigabyte-hour is 0.04 credits. Retention policies are therefore priced decisions the team can state in a plan review, instead of discovering them in an annual bill archaeology.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.