Export Options and Reporting Practices

Developers and analysts often need to share query findings outside the tool UI. Export enables this, but governance still matters. Use this guide to keep exports useful, bounded, and privacy-aware.

When to Export

Export when results need structured review by teammates or non-technical stakeholders.

Avoid exporting broad raw datasets when a focused subset answers the question more safely.

Streaming XLSX Model

DevUtilKit export streams rows to XLSX instead of loading everything in memory at once.

A hard row cap protects service stability and keeps usage aligned with diagnostic reporting intent.

Validation Before Sharing

Review columns and row ranges before export. Remove fields that are not required by the reporting objective.

Always validate totals and sampling assumptions to avoid distributing misleading snapshots.

Data Privacy Considerations

Once exported, data may travel outside runtime controls. Treat exported files according to your organization data classification policy.

Prefer secure internal channels for report sharing and avoid long-lived local copies when unnecessary.

Operational Tips

Add export rationale to incident notes so reviewers understand why a file was generated.

For recurring reports, move from ad-hoc export to governed pipeline workflows.

Copying results for use in other tools

SQL Runner results are shown as plain text tables designed for quick copy operations. To use output in spreadsheets, pull request discussions, or support tickets, select the rendered rows and paste into the destination tool. Many spreadsheet editors auto-detect column boundaries from whitespace or tab alignment. This makes small and medium result sets easy to share without requiring additional export infrastructure for every debugging scenario.

For structured transfer, you can generate comma-separated lines directly in SQL using PostgreSQL string composition functions. A query like selecting identifier, email, and status joined by commas creates output that pastes cleanly into CSV files. This approach works well for one-off sharing when a formal export pipeline is unnecessary. Always confirm delimiter and escaping behavior if fields may contain commas or line breaks, and limit rows to keep manual handling reliable.

When to request a proper data export

SQL Runner is optimized for inspection, not high-volume extraction. Once result size moves beyond a few hundred rows or reporting becomes recurring, copy-paste workflows become error-prone and difficult to govern. The five-second timeout also makes large retrieval impractical in interactive mode. At that point, use a proper export path that supports repeatability, auditing, and downstream processing rather than stretching a diagnostic tool beyond its intended operational role.

Common alternatives include psql backslash-copy commands, full-table dump tooling, scheduled queries in BI platforms such as Metabase or Redash, or scripts using official PostgreSQL drivers in Node.js or Python. These options provide better control for batch workloads and recurring reporting. Choosing the right path improves data quality, reduces manual mistakes, and keeps SQL Runner focused on fast investigative checks where it delivers the most value.