Analytical SQL on MicroSaaS.app
DuckDB served over HTTP for analytical queries. Memory floor: 128 MB (measured floor rounded up to the next multiple of 32 MB). Status: Validated
What was measured?
- At 128 MB it passed a server-side 1M-row load, aggregation and spill checks, 5 forced-stop cycles and 30 parallel unauthenticated 8 MB posts.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
- Uploading a 36 MB Parquet file from the client panicked the VM at 128 MB and passed at 160 MB.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
- On a full volume the server returned a clean disk-full error, stayed up and kept its data.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
| Engine | DuckDB with the Quack extension |
|---|---|
| Category | Database |
| Memory floor | 128 MB |
| Status | Validated |
How long does it live?
Stateful services have a time to live of at least 1 hour, set in whole-hour steps; the default is 1 hour. The maximum depends on the plan: 4 hours on Free, 24 hours on Developer and up to 30 days on Pro. At expiry the service and its data are deleted and cannot be recovered.
What are the limits?
Server-side loads fit the floor; clients that upload bulk data need more memory. The gateway rejects request bodies above about 8 MB.
- The platform gateway rejects request bodies above about 8 MB (HTTP 413).
- Spilling to disk is limited by free volume space, not RAM.
- A DuckDB file does not shrink after a DROP.
A memory floor is not a sizing recommendation.
Where would it be used?
What else is in database?
Last updated