Grid

Services

The decision worth arguing about

The decision that defines this product is what happens in Postgres when a user adds a field. The intuitive answer is a real table per user table and an ALTER TABLE per field, which gives you native types, real indexes and honest planner statistics — and which collapses at scale, because two thousand bases with thirty tables each is sixty thousand tables of catalogue, every schema migration becomes a distributed operation, and a user renaming a column takes a lock on production. So Grid stores records in a shared cell store: typed columns for the common scalar types, JSONB for everything else, and one row per cell rather than per record, which is what makes adding and reordering fields free. The cost is that Postgres no longer holds meaningful statistics for a user's column, so the planner cannot tell a field with three distinct values from one with three million and will happily choose a sequential scan on a view that filters by it. Two mechanisms pay that back. Any field that a view actually filters or sorts on gets a partial expression index created lazily by a background worker the first time it is used — indexes follow real usage rather than every field a user creates. And any view over roughly 100,000 records gets a materialised projection refreshed on write through the queue, so the grid reads a narrow purpose-built table instead of assembling cells at query time. The honest limitation: a base that behaves like a warehouse rather than a workspace should not live here at all, and Grid tells you so by exposing per-view query time in the interface rather than letting it degrade quietly.

Services

The decision worth arguing about

Azure Database for PostgreSQL Flexible Server ties its maximum connection count to the compute SKU, and this workload opens a lot of short-lived connections — every automation run, every webhook, every view refresh — so the built-in PgBouncer goes on early rather than after the first outage. Enabling it in transaction pooling mode is where the non-obvious consequence lands: transaction pooling breaks every session-scoped Postgres feature, and the automation engine was built on two of them. Advisory locks, which are the elegant way to guarantee that one automation does not run twice concurrently on the same record, do not survive a pooled connection because the next statement may arrive on a different backend. LISTEN and NOTIFY, which is how the WebSocket gateway learned about changes on AWS, does not work at all through a transaction pooler. So on Azure the automation lock moves into Redis as a fenced lease with an expiry, and change notification moves onto Service Bus topics with the gateway subscribing per base. Both are more code and more moving parts than the Postgres primitives they replace, and the Redis lease in particular has a failure mode the advisory lock did not — a worker that stalls past its lease expiry can be joined by a second worker on the same record, which is why every automation action is written to be idempotent on a run identifier. We use the same Redis and Service Bus shape on AWS for consistency, but on Azure it is not optional.