When a CSV Is Too Large for Google Sheets, Query First and Publish a Smaller Extract

If Google Sheets reports that a CSV is too large, do not start by cutting the file into arbitrary pieces. First decide whether you need the full dataset in a spreadsheet, a queryable source behind Sheets, or a smaller file designed for readers.

As of September 21, 2026, Google documents a limit of 10 million cells or 18,278 columns for spreadsheets created in or converted to Sheets, and says the same limits apply to Excel and CSV imports (Google Drive Help). A 600,000-row CSV with 20 columns contains 12 million cells before you add formulas or notes, so it cannot fit as one Google Sheet.

Choose the destination before reducing the file

What you need	Best starting point	Result
Edit a dataset that fits below the cell limit	Direct Sheets import	A conventional spreadsheet
Analyze the complete dataset with Sheets tools	BigQuery and Connected Sheets	Full data stays in BigQuery; Sheets provides the analysis interface
Filter or aggregate a large CSV locally	DuckDB or a chunked data workflow	A reproducible query and a smaller output
Give the public an understandable dataset	A documented public extract	A focused table readers can sort, filter and share

Google recommends File > Import rather than copy and paste when ingesting a large supported file. If Sheets says the file is too large to import directly, Google’s documented alternative is to import it to BigQuery and use Connected Sheets (Google Docs Editors Help). This is the right path when analysts genuinely need the complete source and already have an appropriate Google Cloud project.

Connected Sheets does not place every source row into ordinary cells. Its own output surfaces still have limits: Google currently lists 200,000 rows for Connected Sheets pivot tables and 500,000 rows or 5 million cells for extracts (Google Drive Help). Treat it as a query interface, not a way to turn an unlimited table into a normal worksheet.

Build a smaller extract with a query, not a text editor

A publication extract should be defined by a reader question. For example:

• one date range rather than the complete historical archive;
• the geography covered by the article;
• the fields needed to interpret the records;
• one row per relevant observation, rather than a pre-aggregated total that hides detail.

Keep the original CSV unchanged. Save the query beside the extract, and record the source URL, retrieval date, filters, selected columns and row count. If the source changes, you can rerun the same transformation instead of manually repeating a sequence of spreadsheet edits.

DuckDB can read a CSV directly in a SQL query, infer its format, accept explicit column types and write query results back to CSV (DuckDB documentation). This sample creates a public extract from a hypothetical incidents.csv while preserving an identifier as text:

COPY (
  SELECT
    incident_id,
    incident_date,
    region,
    category
  FROM read_csv(
    'incidents.csv',
    types = {
      'incident_id': 'VARCHAR',
      'incident_date': 'DATE'
    }
  )
  WHERE incident_date >= DATE '2025-01-01'
) TO 'public_extract.csv' (HEADER, DELIMITER ',');

Replace the example fields and cutoff with rules justified by your project. Declaring identifier columns as text also helps prevent codes such as 00123 from being treated as numbers; use the CSV leading-zero checklist when validating those fields.

Then inspect the output rather than assuming the query worked:

SELECT
  count(*) AS rows,
  count(DISTINCT incident_id) AS distinct_ids,
  min(incident_date) AS first_date,
  max(incident_date) AS last_date
FROM read_csv('public_extract.csv');

Also compare the output columns with your planned data dictionary, inspect nulls in required fields, and open a sample of records containing commas, quotation marks and non-ASCII text. If the source is released periodically, compare the new and previous CSV versions before replacing a published extract.

When the smaller public extract is the better product

Use an extract when the omitted rows are outside the publication’s stated scope and readers can understand exactly what was retained. A nationwide archive might remain in BigQuery while the page accompanying a regional investigation contains only the relevant places, dates and explanatory fields.

Do not call a file “complete” if it is filtered. Label it plainly, for example:

Records from January 1, 2025 through August 31, 2026 for the North region. Selected from the full agency release retrieved September 15, 2026. Fields retained: incident ID, date, region and category.

Include a link to the full source when licensing and access permit. Report the extract’s row count, explain exclusions, and publish the transformation query where readers can audit it. Never upload confidential, personal or otherwise sensitive records to a public data page.

A cleaned CSV, TSV or Excel file can be uploaded to TablePage to produce a public dataset page with a shareable link and a filterable table (TablePage). That makes the extract easier to explore, but it does not replace provenance: the page still needs a useful title, scope note, field definitions, source attribution and retrieval date.

Avoid three tempting workarounds

1. Deleting columns until the import happens. Remove fields only after deciding they are irrelevant; otherwise you can discard keys, units or qualifiers needed to interpret the data.
2. Splitting rows across tabs in one workbook. The 10-million-cell ceiling applies to the spreadsheet, so extra tabs do not create a new cell budget.
3. Publishing arbitrary chunks. Files named part1.csv and part2.csv make readers reconstruct the dataset and can separate related records. Split by a meaningful dimension only when each part stands on its own.

The practical rule is simple: keep the complete source in a system suited to querying it, and put only the necessary, documented slice into the reader-facing spreadsheet or public page.