Skip to main content

Schema Tab: Reference

This page is the source of truth for the in-app Explain this panels on the Database Explorer detail view's Schema tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

The Schema tab is shown for PostgreSQL, Microsoft SQL Server, MongoDB, and Oracle. Redis and Valkey are key-value stores without a schema model, so the tab is hidden for them — note that their health score's Schema dimension still applies, scored from key-design signals.

Object Counts​

How many objects of each type the database contains — one tile per object type the engine reports.

What each engine shows​

  • PostgreSQL — tables, indexes, views, functions, and sequences.
  • SQL Server — tables, indexes, views, procedures, functions, triggers, and sequences.
  • MongoDB — collections, indexes, and documents. The Documents tile is a volume figure, not a structural one — it moves with data, the others move with schema.
  • Oracle — tables, indexes, views, procedures, functions, triggers, and sequences, plus the Valid / Invalid / N/A validity tiles.

A tile appears only when the engine provides that object type; a zero means the engine reported zero, not that nothing was collected.

How it's calculated​

  • Counts come from the agent's schema inventory: refreshed roughly every 10 minutes on PostgreSQL and MongoDB, every 4 hours on SQL Server and Oracle with default intervals.
  • The change chip compares against the previous comparable period.

Reading it​

Counts are structural pulses — they should move when deployments move them and stay flat otherwise. An unexplained change is precisely what the Changes tab exists for: it names the object, the change type, and when it happened.

Valid​

The number of Oracle objects whose status is VALID — compiled, usable, and serving queries. This tile appears for Oracle databases.

How it's calculated​

  • Oracle tracks a validity status for every object in dba_objects; the agent collects the count of VALID objects with the schema inventory.

Reading it​

In a healthy database this number equals the object total, making the tile pleasantly boring. Its real job is to be the denominator: when Valid drops while Invalid rises, a dependency change just broke compiled objects — and the two tiles together tell you how many.

Invalid​

The number of Oracle objects whose status is INVALID — objects that failed compilation or were invalidated by a change to something they depend on. This tile appears for Oracle databases.

How it's calculated​

  • Oracle marks views, procedures, packages, and similar compiled objects INVALID when their dependencies change; the agent collects the count from dba_objects with the schema inventory.

Reading it​

Zero is the target. Oracle often recompiles an invalid object automatically on next use, so a transient non-zero after a deployment can self-heal — but objects that stay invalid are broken code paths waiting for a caller. Cross-reference the Changes tab for what changed right before the number rose, and recompile or fix what remains.

N/A​

The number of Oracle objects whose validity status is N/A — objects Oracle reports without a valid/invalid state. This tile appears for Oracle databases.

How it's calculated​

  • Some object kinds carry no validity in dba_objects — synonyms are the common case, and partitioned indexes track usability separately per partition. The agent counts them as reported.

Reading it​

This tile is informational, not a health signal: N/A means "validity does not apply," not "unknown problem." A stable non-zero here is the normal state for databases using synonyms or partitioning. For partitioned indexes specifically, the object inventory's Status column is where per-partition usability shows up.

Total Size​

The combined size of the database's objects, summed from the most recent size reading of each object in the selected window.

How it's calculated​

  • The agent collects per-object size metrics on its schema-collection cadence; this tile sums the latest reading per object.
  • It can differ slightly from the Overview tab's Database Size tile, which asks the engine for the database's own size figure — that number includes engine overhead the per-object sum does not.

Reading it​

Use it together with the treemap next to it: the tile says how much, the treemap says where. If Total Size grows while the object count stays flat, existing objects are growing — usually a handful of them, which the treemap makes obvious.

Object Sizes​

A treemap of the database's objects sized by their storage footprint — the fastest answer to "where does the space live?"

How to read it​

  • At the top level, each cell is an object type group (tables, indexes, collections, …) sized by the group's total. Click a group to drill into its individual objects.
  • Inside a group, each cell is one object; very small objects (under a quarter percent of the group) roll up into a dashed Other cell so the long tail doesn't hide the picture.
  • Objects reporting zero size are left out. If everything reports zero — common right after adding a database, before statistics have refreshed — the card says so rather than drawing an empty chart.

Reading it​

Two shapes are worth recognizing. A single dominant cell is concentration risk: one table carrying the database, worth watching in the trend charts. And an index group rivaling the table group in size means the database spends as much space on finding data as on storing it — sometimes justified, often a sign of redundant indexes worth an audit in the objects list below.

Database Objects​

The database's object inventory — every table, index, view, and routine the agent has collected, searchable and sortable, largest first by default.

Columns​

  • Name — the object's name, with a type icon.
  • Type — the object type badge (table, index, view, procedure, function, trigger, sequence, collection — whichever the engine supports).
  • Schema — the schema the object belongs to, where the engine has schemas.
  • Status — object validity where the engine reports it: Oracle objects and index partitions show valid/unusable states, and a warning marker appears when an object's statistics are more than 90 days old.
  • Rows — the row count, where collected.
  • Size — the object's storage footprint.

The list can be searched by name, filtered per column, and paginated; column visibility choices persist in your browser.

How it's calculated​

  • Rows come from the agent's schema inventory for this database — the same collection that feeds the count tiles above.
  • Row counts and sizes are the most recent readings; on engines where statistics drive these numbers, a stale-statistics warning on the Status column means the figures may lag reality.

Reading it​

Sort by Size to find the giants, and by Rows to find the busiest candidates for indexing review. On Oracle, filter the Status column visually for unusable index partitions after bulk loads — they silently stop serving queries until rebuilt. The stale-statistics marker is the quiet one that matters: an optimizer working from 90-day-old statistics makes 90-day-old decisions.