Alloy
Mesh StoragePython SDK

Limits

Boundaries for SDK uploads, reads, hosted SQL, and processing status

The SDK keeps Mesh Storage operations explicit: upload files into SDK paths, read Mesh objects by prefix or key, and query Ready data through hosted SQL.

Upload limits

High-level upload helpers support .mcap, .json, .yml, and .yaml files under:

uploads/sdk-uploads/

The SDK does not expose delete, move, rename, overwrite, raw R2 writes, direct object-store credentials, upload finalize calls, or direct mission creation.

overwrite=True raises immediately. Delete or replace files through Mesh Storage workflows before uploading a replacement.

Read limits

Read helpers list and download Mesh-visible objects by SDK path, raw prefix, or exact key. They do not provide file-id mapping or cross-org access.

The SDK validates final object key length before upload. Mesh object keys must fit the storage provider's key size limits.

SQL limits

Hosted SQL is read-only. The SDK does not expose write SQL, table creation, public Flight SQL/gRPC, Postgres wire protocol, ODBC/JDBC, cursors, sessions, or stream resume.

Processing limits

Uploading a file is not the same as processing it. After upload:

  • Replay and Inspect work once the MCAP lands.
  • SQL requires the file to reach Ready.
  • Failed files need investigation from the Mesh Storage file row.

The SDK does not poll processing status. Use Mesh Storage, SQL Workbench, or MCP tools to inspect readiness.

Dependencies

The base SDK includes the transfer clients required by Mesh Storage. Optional extras are still used for some local result conversions:

FeatureDependency path
Mesh sync transfersincluded
Mesh async transfersincluded
pandas conversioninstall alloy-sdk[pandas]
Polars conversioninstall alloy-sdk[polars]
DuckDB conversioninstall alloy-sdk[duckdb]

If a dependency is missing in a broken environment, the SDK raises a dependency error rather than silently falling back.

On this page