What Grid is not good at.

Joins across 10M rows with sub-second latency.

SQL wins, not close.

A join-heavy workload belongs in Postgres, and the right Grid move is to mirror-project a SQL result set into cells on demand rather than simulate SQL in Grid.

Fixed-schema data that never changes shape.

Postgres wins.

Grid's freedom to reshape cell bodies is a cost when the shape is already settled, you pay for flexibility you are not using.

Multi-cell transactions with rollback.

SQL wins.

Grid's write model is append-then-index; there is no rollback primitive, and adding one would compromise the "every write is durable the moment it lands" discipline.

Full-text search over large corpora.

Elasticsearch / Tantivy / sqlite-fts win.

Grid's study: walks an in-memory index; beyond a few hundred thousand cells that is not what you want for substring queries.

Strong distributed consistency across geographies.

CRDTs plus a real distributed database win.

Grid today assumes one canonical writer per file. Multi-writer replication is a future rung and may never be a primary target.

Workloads where the caller only wants typed records over HTTP.

Postgres + an HTTP layer wins.

If the caller wants REST JSON and has no interest in addresses, projections, refs, or subscriptions, Grid can serve it but you are using zero of what makes Grid special. Use Postgres + an HTTP layer; it is a smaller bet, and the right one when the caller's needs end at the response body.

Low-residence bulk data.

Object storage wins.

A million-cell inert corpus is valid but does not exercise the residence thesis. Do not use that posture as evidence for claims about co-residence.

Any workload where 'the substrate is the agent' is not the point.

Any other tool wins.

If you are not running residents against the grid, you are using Grid as a text-based database with extra steps. That is fine, but it is not what Grid is for.