Schema Explorer
The Schema Explorer is the structural inventory of your monitored databases: which schemas exist, how large they are, what objects they contain, what changed recently, and who can access them.
What the page shows
- One row per schema-like scope: database schemas on PostgreSQL and SQL Server, the database itself on MongoDB, the owner/schema on Oracle.
- Redis and Valkey are key-value stores without a schema model, so they do not appear here.
- Each row carries the schema's size and its active alert counts by severity.
Selecting a row opens the schema's detail view: an overview with health and the object inventory, the change history, the permissions view, and the schema's alerts.
Reading it
This surface answers structure questions without touching data: sort by Size to find the heavy schemas, filter to a database when reviewing a deployment's footprint, and let the alert chips point at schemas whose structure is already causing findings. It is not a data browser — table contents never appear here.
Schema List
One row per monitored schema with its database and hosting instance. Click a row to open the schema's detail view.
Columns
- Schema — the schema's name with its engine icon.
- Database — the database the schema belongs to. Filterable by database.
- Instance — the hosting instance. The top bar's instance selector scopes this page, so the column itself has no separate filter.
- Size — the schema's storage footprint. Filterable by range.
- Alerts — active alert counts as severity chips: Critical, High, Medium, Low.
The list can be searched by schema, database, or instance name, filtered by engine, sorted by most columns, and paginated. Column visibility choices persist in your browser.
Reading it
Two scans cover most sessions: by Size for capacity review, and by Alerts for structural findings that need attention. Because MongoDB represents each database as one schema row, a MongoDB "schema" here is the whole database — its size and alerts read accordingly.
Engine specifics for the list: PostgreSQL and SQL Server rows are database schemas; a MongoDB database appears as a single schema row sized by the database; Oracle currently appears as one aggregate row per database (its schema inventory is collected as per-owner object counts), so per-owner sizes are not listed. Redis and Valkey have no schema model and never appear.
Schema Detail
Selecting a schema opens the Schema Detail view. The header shows the schema with a switcher to jump between schemas of the same database, and the detail view has four tabs:
| Tab | Purpose |
|---|---|
| Overview | Object counts, schema identity, health, the size treemap, and the object inventory. |
| Changes | Detected structural changes with property-level diffs. |
| Permissions | The principal privilege matrix and permission change history. |
| Alerts | Alerts scoped to this schema, plus database-wide alerts not scoped to any schema. |
Metric definitions and how each value is calculated live in the Overview reference, the Changes reference, and the Permissions reference.
Alerts
The Alerts tab combines alerts that name this schema with database-wide alerts that are not scoped to any schema — a schema is affected by both. The health card's per-dimension arrows land here pre-filtered to the alerts behind a dimension.
Data Freshness
Schema and permission data changes less often than runtime activity, and Logstag collects it accordingly: the schema inventory and permissions refresh roughly every 10 minutes on PostgreSQL and MongoDB, and every 4 hours on SQL Server and Oracle with default intervals. Changes are detected when the next snapshot lands, so detection lags the actual statement by up to one collection interval.
If schema data is unavailable, common causes include no collected schema sample for the selected time window, insufficient monitoring permissions, unsupported engine metadata, collector delay, or an inactive database target.
Data Boundaries
Schema Explorer displays structural and access metadata: schema, object, role, and user names, object types and sizes, privilege flags, permission history, and structural change records. Logstag does not copy application table rows, MongoDB documents, or Redis key values through Schema Explorer.
Schema metadata can still be sensitive — object names, role names, definitions, and permission history can reveal business structure and security posture. Access to Schema Explorer should be limited to users who are allowed to inspect database structure and access metadata.