Performance
How Tablify keeps the window responsive and its resource use bounded.
Tablify is a native macOS application written in Rust and drawn on the GPU through GPUI. It carries no browser engine and no virtual machine.
The window
GPUI paints every frame with Metal and paces it against the display, so Tablify runs at the refresh rate of the screen it is on. Scrolling a grid, switching tabs, and typing in the editor are drawn by the GPU, not laid out by a document engine.
Nothing on the interface thread waits on a database. Connecting, querying, fetching, exporting, and writing to disk all happen in other processes, so a slow query leaves the window scrollable and the query cancellable. Cancellation travels its own route and never queues behind the work it is trying to stop.
Animation is capped at 250 ms, and the paths you use constantly do not animate at all. Quick open, tab switching, and the grid appear in place.
Bounded resource use
Tablify never holds a full result set. A table page is capped at 1,000 rows or 4 MiB, a query fetch at 512 rows or 4 MiB, and a single run keeps at most 10,000 rows. The metadata cache holds 256 tables. Exports stream straight to disk as background jobs rather than collecting in memory first.
Every queue, pool, cache, history, and buffer in the backend has a fixed ceiling. None of them are unbounded, and no setting can lift a safety cap.
Install size
The macOS build is about 40 MB on disk, which covers the application, the backend, and the four database drivers. A client built on Electron ships its own copy of a browser and usually installs at several hundred megabytes.
Drivers you never connect to are processes that never start.
Process isolation
Tablify runs as three tiers. The window is one process, the backend that owns sessions, pools, and caches is another, and each database driver is a separate executable started on demand. They talk over a private local channel that is not a network service.
A driver that crashes or hangs fails its own pending work and cannot take down the window or your other connections. Credentials are resolved in the backend from the Keychain immediately before the driver that needs them, so they cross as few boundaries as possible. Database libraries stay out of the application process entirely.
Crossing both boundaries costs a p95 under 2 ms for a full page round trip on Apple Silicon, measured against a test driver so the figure covers the architecture rather than the database.
Timeouts
Every operation carries a deadline, enforced by whichever process owns the cancellable work. Waiting for a pooled connection counts against it.
| Operation | Default | Range |
|---|---|---|
| Database connect | 15 seconds | 5 to 60 seconds |
| Catalog, metadata, and table page | 30 seconds | 5 to 120 seconds |
| Interactive SQL or Redis command | 60 seconds | 1 to 1,800 seconds |
| Export job | 30 minutes | 1 minute to 2 hours |
A timeout sends a native cancel, waits up to two seconds for the database to acknowledge it, then discards the physical connection if work might still be running on it. A connection that may still be busy is never returned to the idle pool.
Stale work
Every asynchronous result carries the session and operation that produced it. If you navigate away, reconnect, or cancel, the answer that arrives afterwards is discarded rather than painted into a context it no longer describes.