Platform · Data

KERNSTACK Tables

Tables are KERNSTACK’s serverless key-value store: each table declares a key (key_name, key_type S or N, optional sort key) and its secondary indexes, items arrive through the typed SDKs, and a table can declare a change_stream that invokes a function whenever items change. There is no SQL layer and no capacity-unit arithmetic — a trade this page states as plainly as the pricing.

NoSQL Tables

Talk to us Read Tables Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Tables

Teams otherwise run a managed database plus a private network, or a document store whose query model quietly becomes the architecture. On KERNSTACK, access patterns are designed into keys up front, storage costs 0.04 credits per GB-hour, and access spends the compute of the code performing it.

Designing with keys

A table is a bet about how the product reads: users by id, orders by customer and timestamp, sessions by device. The key and sort key encode that bet; secondary indexes cover the second read pattern honestly rather than pretending all queries are equal. Seed data lives at seed/tables/{name}.json and uploads after every successful deploy, which is what makes preview environments useful instead of empty.

Change streams: the table announces itself

Setting change_stream: { function } makes the table invoke a function of the same stack with batched changes — new item, old item, change type — whenever items are written or deleted. Failed batches retry with backoff and block later changes until they succeed or age out at 24 hours; handlers should be idempotent off the change id. Fanout, audit trails, and index maintenance all hang off this one declaration.

Key types: S (string), N (number), BIN (binary), B (bool); each index names its own key fields
No read/write capacity units: reads and writes spend the caller’s compute
Tables are the audit pattern’s home: before/after images come free from change records

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call Tables without external credentials:

Go SDK: github.com/coding-berlin/kernstack-sdk-go/sdk_tables
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: Kernstack\Tables

European alternatives to the hyperscaler equivalent

Amazon DynamoDB →

Implementation guides for Tables

Go + Tables → Node.js + Tables → PHP + Tables →

Tables in the Project Graph

Declarestack.jsontables

RunTablesinfrastructure

MeterOne credit balanceEU zone

stack.json — tables configuration plan · deploy

{
  "resources": {
    "tables": [{ "name": "orders", "key_name": "customer_id", "key_type": "S",
      "sortkey_name": "ts", "sortkey_type": "N", "indexes": [],
      "change_stream": { "function": "on-order" } }],
    "functions": [{ "name": "on-order" }]
  }
}

Metering · compute, storage, or network 1 Shared Balance

Storage is 0.04 credits per GB-hour. Egress is 9.00 credits per GiB. Compute beside the data is 0.01 credits per GiB-second.

Replaces: Amazon DynamoDB · Cloudflare D1 · Supabase Postgres

FAQ

Frequently asked questions

Is there SQL or a query language?

The lowest table storage layer is a NoSQL key-value store — keyed and indexed access, by design. Full-text or semantic search can be plugged on top of that layer.

How are tables priced?

Storage at 0.04 credits per GB-hour (about 29 credits per GB-month). Reads and writes are not unit-priced; they consume the GiB-seconds of the function or worker performing them.

Can a table react to its own writes?

Yes — that is the change stream. Declare the target function on the table and it receives batched change records with retry semantics. It must be a function, not a worker.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

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

Talk to us See pricing & credits →