Ten million rows.
Thirty milliseconds.

Multi-column sort and per-column filters, plus an advanced AND/OR filter builder — all resolved in the database.

Filter-by-checkbox value lists with live counts (FACET), computed lazily — only when a filter panel opens.

Users type a question — “revenue over 50k in region Nord” — and a server-side LLM, constrained to the grid’s own columns and operators and re-validated against the allow-list, compiles it exactly like a hand-built filter. Never unsafe SQL; works across all three clients. The safety of the compiled filter was never the gap — the spending was. Until 0.5.0 the config flag meant to switch the assistant off was never read by anything, so ask() was reachable on any grid page with the interface merely hidden, with no length bound and no rate limit on a billed model call. It is a real server-side kill switch now, questions cap at 500 characters, and calls are metered per caller and grid with a limiter that fails closed. 0.7.0 makes the answer explainable, and closes two ways it was quietly wrong. The allow-list has always dropped conditions it cannot permit, and doing so silently left the user with a filter answering a narrower question than they asked; interpret() now reports what was thrown away, and all three clients show it. Deliberately not a model-reported confidence score — a self-reported confidence is not calibrated, and rendering 92% confident invites trust at exactly the moment the filter should be checked, where what was dropped is ground truth. The two wrong answers: a question about a text column holding 00123 bound the integer 123 and matched nothing, a silently empty grid rather than an error, and a half-open between compiled to BETWEEN ? AND NULL and matched no rows — values are coerced by the declared type now and the half-open range is refused and reported. The reverse direction ships too: explain() renders the filter in force as a sentence under the toolbar, and it is not an LLM call, because a filter tree is structured data and describing it is formatting rather than inference — faithful by construction, free, and therefore on every grid rather than only where the assistant is switched on. Switched on by the host, and only by the host: until 0.8.0 a browser could set $assistant to true on a grid that never opted in and run billed calls.

Group by any column with subtotals, non-additive aggregates like median/percentile, and expandable detail rows. This page said WITH ROLLUP until 0.6.0 and that was never how it worked: the rollup flag was documented as the way to get subtotals, plumbed from all three clients through the protocol into the driver contract, and never read by the engine — groupBy was always called with false. Nothing was lost, because the subtotals were never produced by ROLLUP anyway. The engine runs one GROUP BY per level, so each level aggregates over its own rows, which is what makes a median subtotal correct rather than a mean of the cells above it. The dead surface is removed in 0.6.0. Pivot mode arrived in the same release, in all three clients, and rests on exactly that: every subtotal and margin is its own aggregate query rather than a sum of the visible cells, which is the difference between a correct median subtotal and a plausible one. It costs one query per grouping level, issued in parallel — four for a 1×1 pivot — and grouping queries finally have a limit at all, since the number of group rows scales with a column's distinct values rather than the page size. A truncated grouping says so in the response instead of being presented as complete. On PostgreSQL it did not work at all before 0.5.0 — the engine quoted every identifier through the driver except one hardcoded backtick, so a headline feature raised a syntax error on a database this page calls supported. The live PostgreSQL suite never loaded the engine, which is why it survived; there is an engine-level suite now that drives the real thing against a real server.

Classic paging or smooth virtual scrolling — rows and columns virtualized — across all three clients.

Inline, in-cell, modal or slideover editing, with batch edits — validated on the server. Two things 0.5.0 closed that a page selling editing has to say. With any row pinned, paste and copy addressed the wrong record: each client sorted its own copy for display while the core resolved the active cell against the unsorted array, so it was a silent wrong-row UPDATE rather than a wrong paste. And create and update returned the row with SELECT *, handing the client every column in the table — password hashes, tokens, internal flags — where it now returns only the columns the grid declares. Since 0.7.0 an applied mutation fires GridRowChanged with the row before and after over those same declared columns — the boundary the response already respects, so an audit trail cannot leak what the grid does not show — and inverse() gives the mutation that would undo it. For a delete it returns null on purpose: restoring the row would pass through the write allow-list, which strips the non-editable columns including the key, so the restored row would come back with a new id and missing data. An undo that quietly produces a different row is worse than one that admits it cannot be built. Capturing the previous row costs one SELECT, so it happens only when something is listening.

Row and range selection with a complete keyboard spec and clipboard support — spreadsheet-grade navigation.

Expandable master-detail rows and full tree-grid hierarchies, lazily loaded from the server.

Freeze columns left and right, auto-fit widths, reorder and resize — with column virtualization for very wide grids.

Streamed CSV and rich XLSX of the full result set — millions of rows — from a server cursor at constant memory. That was not true of a grid with no key until 0.5.0: such a grid cannot be paginated, so the export buffered the whole result set, contradicting its own docblock while max_export_rows defaulted to null. It refuses without an explicit cap now rather than risking an out-of-memory. The other limit is the connection rather than the memory: a streamed export holds an HTTP response open for its whole duration, and the 1.67M-row benchmark takes about 52 seconds against a 60-second ALB or nginx idle timeout, occupying a PHP-FPM worker throughout. 0.6.0 adds a queued export — progress in the toolbar, then a signed download link — with four gates on that link, because a signed URL is a bearer capability and Laravel's signed URLs do not authenticate: finished, unexpired, owned by the caller, and still permitted by the grid's export policy re-evaluated at download time. The ElyraSQL key-window strategy also walked the key's value range, so Snowflake or ULID-style ids needed around a trillion queries — bounded now, with sparse keys falling back to keyset paging: two queries where there were 1.2e12.

A search box that understands meaning, not just substrings — semantic + full-text (HYBRID) via ElyraSQL.

Tailwind v4-native theming that inherits your palette, accent and dark mode with no configuration.

Localizable UI and persistent grid state (columns, sort, filters) across sessions.