Grid view
Scan rows, columns, filters, and sorting.
Connection-level data workspace
Browse tables, understand schemas, and query each connection in context
Inspect tables, stage supported data and schema changes, trace foreign keys, and work in a query console scoped to each connected database.
- Views
- Grid + JSON + Kanban
- Schema
- Foreign-key ERD
- Console
- SQL + mongosh
- Changes
- Review before apply
Data and schema changes depend on the connected engine, permissions, and transaction behavior. Review the generated command and target before applying changes.
Illustrative interface
Connection / table workspace
Data Explorer
Table / public.orders
Orders
GridJSONKanban
Sample rows: 3 shownSort: created_at descendingNo live execution
| iduuid | customertext | statusenum | totalnumeric | created_attimestamp |
|---|---|---|---|---|
| ord_10482 | Sample customer 01 | Paid | Illustrative $248.00 | 2026-08-28 |
| ord_10481 | Sample customer 02 | Pending | Illustrative $96.50 | 2026-08-28 |
| ord_10480 | Sample customer 03 | Fulfilled | Illustrative $412.20 | 2026-08-27 |
- Paid
id / uuid
ord_10482
- Customer / text
- Sample customer 01
- Total / numeric
- Illustrative $248.00
- Created / timestamp
- 2026-08-28
- Pending
id / uuid
ord_10481
- Customer / text
- Sample customer 02
- Total / numeric
- Illustrative $96.50
- Created / timestamp
- 2026-08-28
- Fulfilled
id / uuid
ord_10480
- Customer / text
- Sample customer 03
- Total / numeric
- Illustrative $412.20
- Created / timestamp
- 2026-08-27
Illustrative table values only - data controls disabled
Data Explorer keeps table data, schema context, and a query workspace tied to one connection. Browse before changing anything, confirm the target, and use the view that makes the records easiest to inspect.
Open your connections or read the Data Explorer documentation.
Browse records in the view that fits the question
Open a connection and move between its Table, Schema, Metadata, and Console tabs. The table surface supports grid, JSON, and Kanban views, so a field-by-field inspection does not have to look like a workflow review and a document-shaped record does not have to be flattened before it can be read.
Use pagination, filtering, sorting, and refresh while narrowing an investigation. Import and export controls are available from the table workspace, but availability still depends on the connected database and your team permissions.
Grid is useful for comparing columns across a page of rows. JSON keeps nested values legible. Kanban groups records by a selected field when the question is about the state of work rather than a single row.
Connection data views
Browse a table in the mode that fits the question.
GridJSONKanban
public.orders / sample| Order | Customer | Status | Total |
|---|---|---|---|
| ORD-1048 | Northwind Supply | Processing | $1,280.00 |
| ORD-1047 | Aperture Foods | Ready to ship | $860.00 |
| ORD-1046 | Cedar Retail | Delivered | $420.00 |
Sample rows only - no live connection or execution
Filtered table summary
Orders by day / last 7 sample days
Read the filtered page
Counts are labelled directly on each bar; the red peak highlights Thursday's 31 orders without making color the only cue.
- FILTER
- status: processing
- TOTAL
- 140 orders
- PEAK
- Thu / 31
Illustrative local data - no live query
JSON view
Inspect the selected record as structured data.
Kanban view
Group records into the available board fields.
Trace the relationships the database declares
The schema view provides an ERD for the connection's declared foreign-key relationships. Use it to see the source and target tables, inspect the participating columns, and keep a table selection connected to its schema context.
The diagram is not a claim that every possible relationship has been inferred. It shows declared foreign keys only. If a relationship is encoded in application logic, a naming convention, or an undocumented value, confirm it separately before treating it as a join rule.
Supported schema changes can be prepared from the schema workspace and reviewed before they are applied. Engine support, permissions, and transaction behavior determine what can actually run. DDL can auto-commit and may not roll back, so review the generated command and its target before execution.
Schema map
Trace the relationships your schema declares.
This ERD shows declared foreign-key relationships only. It does not infer relationships or cardinality.
customers
Table 01- id uuid
- name text
orders
Table 02- id uuid
- customer_id uuid
- status text
order_items
Table 03- id uuid
- order_id uuid
- sku text
Declared foreign keys
- orders.customer_id -> customers.id
- order_items.order_id -> orders.id
Query with connection context visible
The Console is scoped to the selected connection, with schema, table, and result context alongside the query. Use SQL where the connection supports it, or open native mongosh mode for MongoDB work. Keep the connection and selected objects in view while checking a result so a copied query does not lose the database it was meant to inspect.
MongoDB also offers a Zero-SQL bridge for supported SQL-to-aggregation translation. Treat it as a bounded compatibility path, not a substitute for every SQL feature:
- Zero-SQL is SELECT-only.
- Subqueries are not supported.
- Window functions are not supported.
- Some advanced SQL features may be unavailable.
Use mongosh when native MongoDB syntax is the clearer fit. Do not assume all SQL will work on MongoDB through the bridge.
Configured sensitive fields are masked in Explorer and query results. Masking follows the configured fields; review what a connection returns and who can access it before sharing a result.
Connection console
Query each connection with its schema and results in view.
SQLmongosh
SELECT id, customer_id, status
FROM public.orders
WHERE status = 'processing'
ORDER BY created_at DESC
LIMIT 25;Native MongoDB mode
db.orders.find(
{ status: "processing" },
{ _id: 1, customer_id: 1, status: 1 }
).sort({ created_at: -1 }).limit(25)Result context
Results remain scoped to the active connection. Configured sensitive fields are masked in explorer and query results.
Sample query - no live execution
Keep the inspection bounded
Start with the table and fields needed for the question, then add filters and sorting before expanding the result. Refresh when the question needs a new read from the connection rather than relying on a previously displayed page.
When moving between the table and console, keep names qualified by the selected schema or database where the engine requires it. That small amount of context helps a reviewer distinguish similarly named tables across connections and makes a result easier to reproduce in the same workspace.
Stage a change, review the command, then apply it
For supported connections and roles, add rows, edit values, and queue deletes in the table workspace before selecting Review & Save. Data Explorer generates a preview in the connection's applicable form: SQL, mongosh, or Elasticsearch JSON. Review the full statement, operation order, table or collection, and target connection before you run it.
Changes are not identical across engines. A reviewed queue can run inside a transaction where that engine supports the transaction wrapper. Other engines run the queued steps separately and can leave earlier steps applied if a later one fails. Schema changes follow their own engine-specific support and review path.
Deleting rows and altering schemas can be destructive. Cancel the review rather than rerunning a partially applied queue until you have checked which steps already ran. Privileged team roles apply reviewed mutations; this is a review surface, not a promise that every write uses a separate approval workflow.
Staged mutation flow
Review the generated command before a privileged role applies it.
Data and schema changes are supported only where the connected engine and permissions allow them.
- 01
Stage changes
Add rows, edit values, or mark rows for deletion before saving.
- 02
Review command
Inspect the generated SQL, mongosh, or Elasticsearch mutation and its target.
- 03
Privileged apply
A privileged team role applies the reviewed mutation.
Generated command review
1 staged edit / public.orders
UPDATE public.orders
SET status = 'cancelled'
WHERE id = 'ORD-1048';Review the operation, not just the diff
Before applying a staged change, compare the generated command with the intended rows, fields, and connection. For a delete, confirm the identity and filter conditions. For a schema change, confirm the object and consider the effect of an engine that auto-commits DDL.
If the preview reports that there is no transaction wrapper, treat the order of queued operations as part of the risk. A later error can stop the remaining work without undoing an earlier step. Check the connection's behavior before deciding how to recover.
Start from the connection you need
Open your connections to choose a database and inspect its available tables, schema, and console. For setup and feature details, read the Data Explorer documentation.