TablePress hosting for tables with thousands of rows.
A table plugin is fine until the table is real. Then the page is shipping the entire dataset to the browser so it can sort ten visible rows.
The whole table in one response.
The default behaviour sends every row to the browser and does the sorting there, which works beautifully up to a few hundred rows.
Paging and sorting on the server
Ten thousand rows rendered into the page is a multi-megabyte response before any styling. Paging and sorting happen server-side, so the response carries the rows being looked at.
Filtering that uses an index
Searching a large table should be a query, not a scan of a serialised blob. Table data is stored and indexed so filtering stays quick as rows accumulate.
Imports that finish
Tables usually arrive as spreadsheets with thousands of rows. Imports run as batches so a large file completes rather than stopping at whatever the timeout allowed.
Tables that survive a phone
A wide table on a narrow screen is the most common real-world failure. Output is delivered so it scrolls within its own container rather than breaking the page.
Undo a bad import
Re-importing over a curated table is easy to do accidentally. Daily restore points make it recoverable.
Where a table plugin stops working.
Nothing is wrong at two hundred rows. At ten thousand the page weight, the browser sorting and the import limits all fail at once, and they look like three separate problems.
- Paging and sorting performed server-side
- Filtering backed by an index
- Imports run as resumable batches
- Wide tables scrolled within a container
Ten rows, not ten thousand.
The measurement is the response size for a page showing twenty rows, because that is what the visitor asked for and often not what they receive.
What we change for large tables
Every row is about not sending data nobody is looking at.
| Setting | What we do | Why |
|---|---|---|
| Paging and sorting | Performed server-side rather than in the browser | Rendering every row so the browser can sort the visible ten produces a multi-megabyte response for a page showing a screenful. |
| Filter queries | Backed by an index rather than scanning stored data | Table content held as one serialised value cannot be queried, so every search reads and unpacks the entire table. |
| Import runs | Batched so large spreadsheets complete | Tables arrive as files with thousands of rows, and an import that stops part way leaves a table that looks populated and is not. |
| Narrow-screen output | Scrolled within its own container | A wide table is the most common cause of a page scrolling sideways on a phone, which breaks the layout around it rather than just the table. |
| Pre-import restore point | Taken before overwriting an existing table | Re-importing over a curated table is an easy mistake and an expensive one to reverse by hand. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
How many rows can a table have?
Why is my table search slow?
My import stopped part way. What happened?
Why does my page scroll sideways on mobile?
Ship the rows people asked for.
Move the site across. Migration is free, table data included.