The schema registry

DynamoDB tables are schemaless, so Dynomatic builds its own picture of yours by watching the results you read. That picture is the schema registry, and it is what makes attribute pickers, projection lists and Data Model inference possible. You do not have to set it up. It fills in as you work.

What gets recorded

Every query and scan result is observed off the hot path, so profiling never slows a read down. From each result Dynomatic records the attribute paths it saw, their types, how often each one was present, redacted samples of the values, entity observations and key samples.

The record is additive per table, a living schema that only grows. It also accrues candidates for a type discriminator attribute, with a candidate that fails staying disqualified rather than flickering back.

What it powers

The registry is the reason several surfaces know your attributes before you have told them anything.

• The Add filter attribute list in the query builder, and the attribute pickers in schema queries.
• The Projection pill, which lists the attributes previous reads have returned. An attribute that has never come back in a result is not listed, and a table nothing has read yet is read in full on its first scan, which teaches the projection.
• The PartiQL editor’s schema-aware warnings, such as an attribute that is not among a table’s sampled attributes.
• Nested path suggestions when you type a map path into a condition pill.
• Data Model inference, which derives entities, key templates, collections, access patterns and relationships entirely from these observations.

The Data Model header states how much evidence the current model rests on, for example 38,540 observations · inferred 2 days ago. More observations make the inferred model sharper, so running a few real queries before inferring is worth the read units.

Where it lives

Everything the registry records stays on your machine, in Dynomatic’s local SQLite database alongside your other app data. Value samples are redacted before they are stored. Nothing is sent anywhere unless you explicitly ask for it, which today means the opt-in AI enrichment pass in the Data Model tab, and that sends structure only, never item data.

Note: Dynomatic also has a scheduled background capture that scans a table on an interval within item and read unit budgets, pausing whenever the app is not the focused window. Its entry points are not currently exposed in the app, so in practice capture happens as you query and scan.

Clear what a table has learned

Captured evidence can go stale. An entity you deleted months ago keeps appearing because its items were observed once, and re-inferring alone will not clear it, because the observations are still there.

To start over for one table, open its Data Model tab, choose More actions, then Reset captured data… and confirm. This deletes everything observed about that table, meaning attributes, entities, key samples and classifications, along with the inferred model. What you set yourself is kept, including relationships, annotations, the design flavor and capture settings. The next capture starts from scratch, so run a query or a scan afterwards to begin rebuilding the picture.