## TL;DR

Never pull the full result into the notebook: add LIMIT, page through results, or write directly to a file or table.
The %%sql magic materializes every row in kernel memory and tries to render them, which spikes RAM and truncates the display.
Push aggregation to the database and fetch only the slice you need.

```text
ipython-sql result set too large: display truncated, kernel memory spiked
```

## Use this when

- A %%sql query returns millions of rows and the kernel memory spikes
- The display shows a truncated table and the notebook becomes sluggish
- The kernel dies after a large SELECT

## Not for this skill when

- The connection string is rejected - that is item 126
- The query itself errors in the database - that is a SQL problem
- Results are small but render slowly - that is a display formatting problem

## Steps

1. Stop the bleeding: interrupt the kernel if it is still materializing rows.
   Expected: the kernel returns to idle.

2. Rewrite the query with a LIMIT and an ORDER BY for a first look: SELECT ... LIMIT 1000.
   Expected: fast results that fit in memory.

3. Move aggregation into SQL: GROUP BY, COUNT, and filters in the database, not in pandas after fetching everything.
   Expected: the result set shrinks by orders of magnitude.

4. For full extracts, write server-side: use COPY or an UNLOAD-style export to a file or table instead of returning rows to the notebook.
   Expected: the data lands in storage without passing through kernel RAM.

5. If you must page through data, fetch in chunks with LIMIT and OFFSET (or keyset pagination) and process each chunk.
   Expected: steady memory usage across pages.

## Tool compatibility

ipython-sql, SQLAlchemy 2.x, PostgreSQL / MySQL / SQLite

## Variant phrasings

### ipython-sql large result memory

Same fix applies: see the Steps section above.

### %%sql result too large truncated

Same fix applies: see the Steps section above.

### %%sql query OOM kernel

Same fix applies: see the Steps section above.

## Why it happens

The %%sql magic fetches the entire result set into a Python list and then renders it as HTML, so memory cost is the full result plus display overhead. Databases happily return 10M rows; the notebook kernel cannot hold them. The display truncation is a symptom, not protection: by the time the renderer gives up, the rows are already in RAM. Databases are built for this - filtering, aggregating, and exporting server-side keeps the kernel as a thin client instead of a doomed warehouse.

## Edge cases / pitfalls

- OFFSET pagination on huge tables gets slower per page; prefer keyset pagination on an indexed column.
- Fetching into pandas does not fix the memory problem; the rows still cross into Python first.
- A LIMIT without ORDER BY returns arbitrary rows; always pair them when sampling.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Okp7hhomYJWgadf5z--1jg