Skip to main content

​
Limits

The ~4 MiB script ceiling covers the whole SQL script sent over the REST query path — which is also what telnyx-edge storage sqldb execute --file and migrations apply use. 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 seed file needs splitting across several calls. 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.

​
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.