SMF·SEATABLE-CLOUD
Can a prompt replace SeaTable Cloud?
Databases — spreadsheet databases and operational data apps
Exhibit tracking slip
Verdict
Most spreadsheet-databases are a row store with a nice interface, and they slow to a crawl somewhere in the tens of thousands of rows. SeaTable's distinguishing property is that it was built to hold far more than that. Reproducing it means putting the same grid and view model over a columnar store, where filtering and aggregating a million rows is instant — which is a genuinely different engineering problem from the other entries in this category, and a real fortnight of work.
Exhibit A — The prompt
Received on31.07.2026Build a spreadsheet-database whose defining property is that it stays fast at a million rows.
Storage: a columnar engine rather than a row store — DuckDB over Parquet files, one file set per table, with an append log for recent writes compacted on a schedule. Fields typed as text, number, date, boolean, single select, multi select, and link to another table. The type system exists to let the storage layer do its job, so it is deliberately smaller than a row-store product could afford.
Why this matters, and what to test: filtering, sorting, grouping and aggregating are the operations that make a table useful and the ones that collapse first at scale. Ship a benchmark command that generates a synthetic table of one, ten and a hundred million rows and reports timings for: a filtered scan, a group-and-sum, a sort on a non-indexed column, and a single-cell update. Publish those numbers in the README. A database product that does not state its own performance is asking to be taken on faith.
Grid: virtualised rendering so scrolling a million rows is smooth — only visible rows exist in the DOM, with row height fixed to keep scrolling calculations trivial. Column resize, reorder, freeze, and inline editing. Paste from a spreadsheet into a range.
Views: a view is a saved filter, sort, group, field subset and row height, named and shareable by URL. Grid, kanban grouped by a select field, and gallery. Views must be computed by the storage engine, never by fetching every row and filtering in the browser — that is exactly what breaks at scale.
Writing at scale: a single-cell edit appends to the write log and is visible immediately. A bulk edit across a filtered selection of a hundred thousand rows runs as one engine operation with a progress indicator and is transactional. Import a CSV of a million rows with a progress bar and a per-column type inference the user confirms before it commits.
Aggregation bar: per-column summaries (count, sum, average, min, max, distinct count) computed over the current view, updating as filters change. This is the feature that most obviously separates a columnar store from a row store, so make it always visible.
API: a REST endpoint per table with filter, sort and pagination by cursor, returning only requested fields.
Backups: scheduled export of every table's Parquet files plus the schema, with a documented and tested restore.
Out of scope: real-time collaborative editing, an automation or plugin system, an app-building layer, and any hosted multi-tenant deployment. Note in the README that SeaTable's own community edition is open source and self-hosting it is a legitimate alternative to this build.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 real-time collaborative editing with other people in the same table
- B.2 the automation and plugin ecosystem
- B.3 managed backups and someone else's uptime
- B.4 the app-building layer on top of the tables
Prior art
Exhibit C — Why people still pay: data model flexibility, collaboration, and integrations
Because a shared operational table is only useful when several people can be in it at once, and multi-user editing with conflict handling is a much larger problem than storage.
Questions
Can I import my SeaTable base?
Yes. SeaTable exports tables as CSV and XLSX, and the type inference on import handles the common cases. Views, formulas and links between tables need rebuilding, and formulas in particular will not map because this build's expression support is deliberately smaller.
Why a columnar store for a spreadsheet?
Because the operations that make a table useful at scale — filter, group, aggregate — are exactly what column stores are built for. A row store has to touch every row to sum a column; a column store reads one column. That difference is invisible at ten thousand rows and decisive at ten million.
What does it cost to run?
A VPS with enough disk for the Parquet files, so ten to twenty dollars a month for a table set in the tens of gigabytes. Columnar compression is good, so a million-row table is usually smaller than the CSV it came from.
What is the one thing that does not survive the rebuild?
Two people in the table at once. Real-time collaborative editing means operational transforms or CRDTs over a shared document, and a columnar store with an append log is close to the opposite architecture. This build is fast and single-writer; SeaTable is shared.
Related tools
Receipt