What you declare for a table
key_type S is a string key and N is a number key. Optional indexes on the table repeat that key shape. A change stream can name a function in the same project when a row changes. The table is not placed on a private network you manage.
Storage is 0.04 credits per GB-hour. Compute beside the table is 0.01 credits per GiB-second. Reviewers see the key and any index in the plan diff before deploy.
What stays behind in DynamoDB
A DynamoDB table description is not the KERNSTACK entry. Billing mode, provisioned capacity, contributor insights, global tables, and the AWS stream view type are not copied.
You declare the key the application will use. You do not export the table and expect its indexes and capacity settings to reappear. If you need an index, you add it on the table entry yourself.
Amazon DynamoDB vs KERNSTACK on European Bare Metal
| Dimension | Amazon DynamoDB | KERNSTACK Tables |
|---|---|---|
| Operator | AWS account | KERNSTACK project |
| Manifest | Amazon DynamoDB console or API | resources.tables, key_name, key_type |
| Region | AWS region list | European bare metal |
| Bill | Amazon DynamoDB line item | One project credit balance |
Frequently asked questions
No. You set name, key_name, and key_type. Capacity mode, global secondary indexes, and stream settings are not copied.
S for a string and N for a number. The key is declared on the table, not inferred from an AWS export.
No. The table is a project resource. It is not a managed database plus a network you peer.
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.