Node.js · Tables Implementation

Node.js with KERNSTACK tables

Node.js accesses KERNSTACK Tables through the typed Node SDK: build a TablesClient from an access key set — injected as environment variables inside deployed workers — and read and write the tables declared in stack.json. Sessions, feed items, carts, and counters become keyed operations in a store the project owns, at storage prices, with no database process to babysit.

NoSQL Tables stack.json IaC

Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Node.js Tables

The mental shift for Node teams is small and permanent: stop thinking in connections and pools, start thinking in keys. A session is a row by session_id with an expiry the handler enforces; a feed is rows by user_id sorted by ts, paginated by key cursor. Those two patterns cover a surprising majority of what product backends ask a database for.

Declarations keep the code honest. The table’s key and sort key live in stack.json, seed files populate previews, and a table that must react to writes declares its change_stream — although note the stream’s target must be a Go function, so Node-heavy projects route reactions through a small Go handler or a workflow.

Pricing is the quiet benefit: storage at 0.04 credits per GB-hour and access folded into the worker’s GiB-seconds. There is no per-query unit table to decode at 2 a.m. when traffic doubles.

CLI

Plan Node.js Tables, then deploy.

Terminal — CLI workflow kernstack cli

kernstack add worker --name api --blueprint work-nodejs-minimal
kernstack plan
kernstack deploy

Docs for Node.js Tables. Tables on the platform.

nodejs-tables.txt Node.js

kernstack add worker --name api --blueprint work-nodejs-minimal
# inside the worker (keys arrive from the environment in deploys):
#   const { TablesClient, TablesClientConfig, DZone, newAccessKeySet } = require('kernstack-sdk');
kernstack plan && kernstack deploy

stack.json — Node.js + tables plan · deploy

{
  "resources": {
    "workers": [{ "name": "api", "runtime": "nodejs" }],
    "tables": [
      { "name": "sessions", "key_name": "session_id", "key_type": "S", "indexes": [] },
      { "name": "feed", "key_name": "user_id", "key_type": "S", "sortkey_name": "ts", "sortkey_type": "N", "indexes": [] }
    ]
  }
}

FAQ

Frequently asked questions

How does the Node worker get credentials?

From the platform-injected environment (access key id, secret, zone) used to construct the SDK’s access key set. Locally you pass your own set. Credentials never appear in the repository.

Can Node code react to table changes?

Change streams target Go functions only. The common Node pattern is a thin Go stream handler that starts a workflow or invokes the Node worker — or polling-free designs where writers call the worker directly.

Is this a MongoDB/Redis replacement?

For keyed access patterns — sessions, feeds, carts, counters — yes, with the honesty that there is no query language beyond keys and declared indexes. Document-database habits map well; ad-hoc query habits are the boundary.

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 →