Skip to main content

​
Limits

The ~4 MiB remote script ceiling covers the whole SQL script sent over the REST query path — which is also what telnyx-edge storage sqldb execute --remote --file and migrations apply --remote use. This request-size limit does not apply to execute --local --file or local migrations. The service advertises an 8 MiB gate and returns the 413 past it, but the transport underneath rejects anything over roughly 4 MiB (4,194,304 bytes, less a few hundred bytes of envelope) with a 422 whose detail ends in stream too large — so ~4 MiB is the number to plan against, and a large remote seed file needs splitting across several calls, or importing through storage sqldb import when it is within that command’s 100 MiB limit. Result sets are capped at the same ~4 MiB, per statement. A query whose rows exceed it fails with a ResourceExhausted … trying to send message larger than max error, through REST and through the env binding alike. Only shipping the rows is capped — computing over the same data server-side (length(), aggregates) is fine — so page through large reads instead of selecting them whole. The 2 MiB cap applies only to values passed through .bind(). A value produced inside SQL is never bound and never checked, which is why randomblob(100000000) stores without complaint. Keep anything approaching either figure — images, archives, model weights — in object storage and bind the key instead. Database size and bound-value size come from the SQLite storage engine that SQL Databases share with per-actor SQLite, so the same numbers apply on both surfaces.

​
SQL dump import and export limits

The 4 GiB export ceiling does not imply that a dump of that size can be restored through storage sqldb import. Imports validate the whole dump before applying batches; each batch is atomic, but the full import is not. If a later batch fails, earlier batches remain applied.

​
Query Performance

A database is served by one primary, and statements run one at a time. A long statement delays everything else queued against that database, so the useful discipline is keeping individual statements short. Add indexes on the columns you filter and order by, page through large result sets instead of selecting them whole, and maintain a summary table on write rather than aggregating across millions of rows on read. Long analytical scans belong in a warehouse, not here.