Structure & indexes

Inferred shape

The store is schema-free, so there is no schema to read. This page samples documents and reports what they actually contain: every path, its type, how often it is present, and an example value.

A field below 100% is simply absent from some documents. That is not a defect to fix — it is the shape of your data, and seeing it is usually the point. Because it is a sample rather than a scan, treat it as a description, not a contract.

Above the table: document count, distinct fields seen, total JSON size and the largest single body.

Indexes

One click creates a JSON property index on any path, named exactly as DocumentDb names its own (idx_json_{Type}_{field}), so an index made here is indistinguishable from one the library made. Enter several comma-separated paths to build a composite index.

The list covers every index on the table, not only DocumentDb’s — an index someone added by hand is often exactly what explains a query’s speed, and hiding it would make the tool lie by omission. External ones are labelled and cannot be dropped from here.

Where the engine tracks it, each index shows its size and how often the planner has used it:

Provider	Size	Scans
PostgreSQL	✅	✅
SQL Server	✅	✅ (resets with the instance)
Oracle	✅	—
SQLite, MySQL, MariaDB, DuckDB, CockroachDB	—	—

Where a number isn’t available it shows — rather than a fabricated zero. An index the planner has never used is flagged unused — on SQL Server that means “not since startup”, because the counter resets.

The query console offers the same one-click index creation from the other direction: run a query, read its plan, and index the fields that query actually filters or sorts on.

Envelope

Underneath, a short reference for the five columns every DocumentDb table has — Id, TypeName, Data, CreatedAt, UpdatedAt — and what each one means. It is the map you need to write anything useful in the raw SQL mode, since the string grammar addresses fields inside Data and not the envelope.