How to open and inspect a DuckDB file in your browser

Start with the database overview

The Overview page summarizes schemas, tables, views, column counts, estimated row counts, file size, and the DuckDB version. Rather than opening rows immediately, it is easier to understand which schemas contain which objects and which tables appear large before choosing where to inspect.

A DuckDB database may contain views as well as physical tables. Scan the table and view names first and open the objects that seem relevant to your task. Estimated row counts are intended as a scale indicator rather than an exact count of every row.

• Schemas / tables / views
• Column counts and estimated row counts
• File size and DuckDB version

Open a table or view and narrow the rows and columns

After choosing a table or view, browse data in pages of 100 rows. Use search, column filters, and sorting to reduce the view to the range that matters. Nested LIST, STRUCT, and MAP values can be opened in a detail view for closer inspection.

CSV and JSON export from the data browser applies to the currently displayed page. This avoids expanding a very large relation into browser memory all at once, so treat export as a way to keep the portion you inspected rather than as a full-database conversion workflow.

Profile only the columns you need to understand

When you identify a column that needs closer inspection, run profiling only for that column. Available checks include NULL counts, estimated distinct counts, numeric summaries, date ranges, text-length summaries, and common values, which can help confirm whether the data matches your expectations.

Column profiling does not automatically scan every column. Large databases can make profiling CPU- and memory-intensive, so first inspect the overview and a few pages of data, then profile only the columns that answer a specific question.

• NULL and estimated distinct counts
• Numeric summaries, date ranges, and text lengths
• Common values

Use guarded read-only SQL for deeper checks

When the browser view is not enough for a filter or aggregation, the SQL workspace accepts one SELECT, WITH, VALUES, SHOW, DESCRIBE, DESC, or EXPLAIN statement at a time. Write operations, DDL, ATTACH, extension loading, environment changes, and multiple statements are rejected before execution, and the database itself is opened read-only.

SELECT-style results are limited to 1,000 rows for display and export. The workspace is therefore best used to answer focused questions rather than dump an entire large dataset. SQL history exists only in memory for the current database session and is cleared when another database is opened.

Save a data dictionary or compare database structure when needed

If you want a record of the database structure, export a data-dictionary HTML containing schemas, tables, views, column definitions, view SQL, and column profiles you explicitly ran during the current session. It does not include table rows, but a completed profile can include common values, so review the report before sharing it externally.

To compare two DuckDB files, the structural comparison shows differences in schemas, tables, views, column definitions, view SQL, and estimated row counts. It is not a row-by-row diff that identifies inserted, updated, or deleted records. Use SQL or another data-comparison workflow when you need to compare the actual row contents.

Tips and limitations

• For an unfamiliar schema, start with Overview to understand tables, views, and approximate scale before reading rows.
• Large databases and expensive views can make search, profiling, and comparison CPU- or memory-intensive, so narrow the scope first.
• A data-dictionary HTML excludes table rows, but it can include common values from column profiles you ran. Review it before external sharing.
• Databases that depend on incompatible DuckDB versions or optional extensions may not open in the browser build.