Kanject DynoStudio

A desktop DynamoDB system studio. Model tables from scratch, inspect live data, run typed queries, build reports, and provision S3 Tables analytics replicas for work that should move off the live table — with the native request and cost behind every action disclosed before it ships.

If you are still building your DynamoDB mental model, start with DynamoDB basics first. It explains tables, items, partition keys, sort keys, GSIs, Query, Scan, and access-pattern-first modeling before the DynoStudio-specific dialect gets advanced.

Workspaces and stages

Everything lives in a workspace: your schema, your stages (dev, staging, prod), and the connections that belong to each stage. A connection is always scoped to a stage — there is no free-floating "current connection" to point at the wrong account. Stages can be marked read-only, and a read-only stage refuses writes on every surface: the PartiQL console, the item editor, saved functions, transactions. Not greyed out — refused.

Connect with IAM SSO or access keys; credentials never leave your machine. No connection at all is also a valid state — schema-only mode lets you design and validate access patterns offline.

Model first, code optional

Start from a blank model, inspect a live table, or paste annotated .NET POCOs when your application already carries the schema in code. DynoStudio keeps tables, entities, key templates, GSIs, access patterns and generated functions together instead of making the model a second artifact.

using Amazon.DynamoDBv2.DataModel;using Kanject.Core.NoSqlDatabase.Provider.DynamoDb.Abstractions.Interfaces;using Kanject.Core.NoSqlDatabase.Provider.DynamoDb.Annotations.Attributes;​[DynamoDbGsi(Name = "Gsi1Index")][DynamoDbGsiAlias<ProductEntity>(name: "Gsi1Index", alias: "SellerProduct")][DynamoDbGsiAlias<OrderEntity>(name: "Gsi1Index", alias: "CustomerOrder")]public abstract record CommerceEntity : IDynamoDbEntity{    [DynamoDBHashKey("pk")] public virtual string PartitionKey { get; set; } = "";    [DynamoDBRangeKey("sk")] public virtual string SortKey { get; set; } = "";    [DynamoDBGlobalSecondaryIndexHashKey] public virtual string Gsi1Pk { get; set; } = "";    [DynamoDBGlobalSecondaryIndexRangeKey] public virtual string Gsi1Sk { get; set; } = "";}​public record ProductEntity : CommerceEntity{    [KeyTemplate("Products#{Id}")]    [DynamoDBHashKey("pk")]    public override string PartitionKey { get; set; } = "";​    [KeyTemplate("Info#{SellerId}")]    [DynamoDBRangeKey("sk")]    public override string SortKey { get; set; } = "";​    [KeyTemplate("Seller#{SellerId}#Products")]    [DynamoDBGlobalSecondaryIndexHashKey]    public override string Gsi1Pk { get; set; } = "";​    [KeyTemplate("ProductInfo#{Id}")]    [DynamoDBGlobalSecondaryIndexRangeKey]    public override string Gsi1Sk { get; set; } = "";}​public record OrderEntity : CommerceEntity{    [KeyTemplate("Orders#{Id}")]    [DynamoDBHashKey("pk")]    public override string PartitionKey { get; set; } = "";​    [KeyTemplate("Info#{CustomerId}")]    [DynamoDBRangeKey("sk")]    public override string SortKey { get; set; } = "";​    [KeyTemplate("Customer#{CustomerId}#Orders")]    [DynamoDBGlobalSecondaryIndexHashKey]    public override string Gsi1Pk { get; set; } = "";​    [KeyTemplate("OrderInfo#{PlacedOn}#{Id}")]    [DynamoDBGlobalSecondaryIndexRangeKey]    public override string Gsi1Sk { get; set; } = "";}

From that model the Functions surface derives typed access patterns — GetProductById, ListProductsBySeller, ListOrdersByCustomer — each with a live key preview as you fill in parameters, and the equivalent AWS SDK call available to copy after every run. The visual model builder renders the same model as entity cards joined by GSI relationship curves; annotated code import is a shortcut, not a requirement.

And DynoStudio does not impose a modeling philosophy. Single-table, multi-table, or both — model one table or many, per service or per bounded context, and the studio reads, queries, and discloses the cost of whichever design you chose. One table or many: modeling across services walks that choice, including why microservices keep a table per bounded context.

One Data workspace, four ways in

The PartiQL dialect has its own layered reference: if DynamoDB is new to you, read DynamoDB basics first; otherwise start at the series overview and pick your entry point — anywhere from a first SELECT to all-or-nothing transactions.

Transparency by default

Every query surface carries the "Executes as" strip: the exact native DynamoDB request the statement translates to, live as you type, with one-click copy. The editor analyses statements at the keystroke — a predicate that degrades to a full-table Scan flags amber with the table's live item count, key conditions tint green, and anything that won't run is squiggled with the reason before it can reach the wire.

• Query history per workspace, with replay from the ⌘K palette
• CSV / JSON export, plus the run's reproducible AWS CLI form
• AWS SDK C# code generation for any run — and the Kanject repository call when the run came from a derived function
• S3 Tables analytics replica plans with native AWS calls, permissions and recurring costs disclosed before consent
• Session restore: your tabs and workspaces come back where you left them