Estimate query result set size from row count, row width, and protocol overhead. Plan network bandwidth and client memory needs.
When you execute a database query, the result set travels from the server to the client over a network connection. The total transfer size isn't just rows multiplied by row width—protocol overhead, column metadata, framing, and serialization formats add significant extra bytes. For large result sets, this overhead determines whether a query completes in seconds or overwhelms client memory.
This calculator estimates the total result set size by multiplying estimated rows by average row size and adding protocol overhead. It helps you decide whether to paginate results, use streaming cursors, or apply server-side aggregation. Understanding result set size is essential for API design, client memory budgeting, network capacity planning, and avoiding out-of-memory errors in application code.
Whether you're building a report that returns millions of rows or designing a REST API endpoint, knowing the payload size in advance lets you make better architectural choices.
Precise measurement of this value supports informed infrastructure decisions and helps engineering teams optimize system architecture for both performance and cost efficiency.
Underestimating result set size causes client-side OOM errors, network timeouts, and slow API responses. This calculator gives you a quick estimate so you can decide whether to paginate, stream, or aggregate before shipping a query to production. Regular monitoring of this value helps DevOps teams detect anomalies early and maintain the system reliability and performance that users and business stakeholders expect.
result_size = estimated_rows × avg_row_bytes + estimated_rows × protocol_overhead_per_row + fixed_overhead
Result: 66.76 MB
500,000 rows × (120 + 20) bytes per row = 70,000,000 bytes (66.76 MB) plus 1 KB fixed overhead. On a 100 Mbps connection this transfers in approximately 5.3 seconds. Consider pagination or streaming for this volume.
Binary protocols (PostgreSQL binary, MySQL compressed) are the most compact. Text protocols add type conversion overhead. JSON and XML are the most verbose due to repeated key names and escaping. Choose the smallest format your client library supports.
LIMIT/OFFSET works for simple cases but becomes slow at high offsets. Keyset pagination (WHERE id > last_id ORDER BY id LIMIT n) is O(1) regardless of page depth. Cursor-based pagination maintains server-side state and is ideal for sequential scans of large result sets.
Estimate peak concurrent queries and multiply by average result set size to get peak bandwidth. A BI dashboard with 20 concurrent queries each returning 50 MB needs 1 Gbps burst capacity. Factor in compression and caching to reduce actual bandwidth consumption.
Protocol overhead includes row headers, column type descriptors, null bitmaps, length prefixes, and framing bytes. PostgreSQL's wire protocol adds roughly 10–20 bytes per row. MySQL adds 12–40 bytes. ODBC and JDBC drivers may add additional buffering.
JSON adds column names to every row, plus quotes, colons, commas, and braces. A row that is 100 bytes in binary might be 200–300 bytes in JSON. For large result sets, consider binary formats like Protocol Buffers, MessagePack, or Apache Arrow.
Yes. Many database drivers load the entire result set into memory by default. A 500 MB result set will consume at least 500 MB of client heap. Use streaming or cursor-based fetching for large results to limit memory consumption.
Run EXPLAIN on your query to see the planner's estimated row count. For more accuracy, use EXPLAIN ANALYZE on a staging database. Alternatively, query table statistics (pg_class.reltuples, information_schema) for a quick approximation.
Absolutely. Enabling gzip or zstd on the database connection or API layer reduces transfer size by 60–80% for text data. Binary data compresses less. The tradeoff is CPU usage for compression and decompression.
Fixed overhead includes the initial column description packet, authentication handshake data, and query status messages. It is typically 0.5–2 KB and is negligible for large result sets but meaningful for tiny ones.