PHP · Tables Implementation

PHP with KERNSTACK tables

PHP workers read and write KERNSTACK Tables through the typed PHP SDK: construct a TablesClient with the zone and the access key set the platform injects as environment variables, then work with the tables declared in stack.json. The LAMP-era pattern — application logic plus keyed storage — survives; the database server, its backups, and its 3 a.m. pages do not.

NoSQL Tables stack.json IaC

Talk to us Read Technical Documentation → Software Lifecycle Cloud →

PHP Tables

The declaration does the schema work PHP teams otherwise hide in migrations: the catalogue table keys by SKU with a declared category index, the sessions table by session id. Code performs keyed operations against a designed store, and a reviewer sees the access patterns in the manifest before seeing a line of PHP.

Client construction follows the platform’s credential model. In deploys, the access key id and secret arrive as environment variables (never in the repository), the SDK builds the key set, and the same code runs locally with a developer’s own keys. Configuration becomes one of the few things that genuinely differs between environments — and it is declared, not improvised.

The honest boundary deserves repeating on the migration ticket: there is no SQL. Queries are keyed reads and declared indexes, paginated by cursor. Applications whose data genuinely fits keys — most product backends — gain storage-priced simplicity at 0.04 credits per GB-hour; reporting belongs beside it as exports and search indexes.

CLI

Plan PHP Tables, then deploy.

Terminal — CLI workflow kernstack cli

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

Docs for PHP Tables. Tables on the platform.

php-tables.txt PHP

kernstack add worker --name web --blueprint work-php-minimal
# inside the worker:
#   $client = new TablesClient(new TablesClientConfig(DZone::..., $accessKeySet));
kernstack plan && kernstack deploy

stack.json — PHP + tables plan · deploy

{
  "resources": {
    "workers": [{ "name": "web", "runtime": "php", "http_port": 8080 }],
    "tables": [
      { "name": "catalog", "key_name": "sku", "key_type": "S", "indexes": [
        { "name": "by_category", "key_name": "category", "key_type": "S" }] },
      { "name": "sessions", "key_name": "session_id", "key_type": "S", "indexes": [] }
    ]
  }
}

FAQ

Frequently asked questions

How does PHP code authenticate to tables?

Through the SDK’s access key set, built from the zone and the platform-injected key environment variables in deploys, or your own key set locally. The repository carries references to secrets, never their values.

Can we migrate MySQL data into tables?

As a reshape, not a dump: export rows, map them to key and sort-key designs, load them as seed files (or through a one-off worker), and verify reads against the old system. The exercise usually deletes half the tables — joins that existed for the database, not the product.

What does table access cost from PHP?

Storage at 0.04 credits per GB-hour, plus the PHP worker’s GiB-seconds while it reads and writes. No per-query units, no connection tier to buy.

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 →