Optional analytics near your storage

The landing-page diagram describes a customer-built architecture, not a managed potluckdb query service or a built-in remote-query API.

  1. The app continues using its local potluckdb database for everyday work.
  2. The customer provides a query endpoint on EC2 or comparable compute. That service uses an appropriate potluckdb SDK and the optional DuckDB execution engine to run analytical reads of a snapshot.
  3. Compute is placed near the bucket, typically in the same cloud region. Size the instance, memory, cache, local disk and network bandwidth for the workload.
  4. The query service sends the result back to the app. It does not need to send the full database to that app to answer the analytical query.

The SDKs cover web, mobile, desktop and server environments; platform/language combinations and analytical-engine availability follow the published compatibility matrix. The customer implements the query endpoint, its access controls and the app's routing to that endpoint.

Capacity depends on the customer’s compute and workload. This page does not claim a measured potluckdb terabyte benchmark or fixed query speed. The separate one-million-row comparison is the measured analytical experiment. General DuckDB larger-than-memory support is useful context, not proof of a specific potluckdb deployment's capacity.

Ordinary device synchronization still works through the storage bucket. This optional analytical setup adds customer-managed compute and its costs; it is excluded from the site's storage-only price chart.

Reference notes

Reviewed 30 September 2026. Architecture illustration; no EC2 instance or external query service was provisioned by this website work.