SurrealDB on MicroSaaS.app
Multi-model database, one instance and volume per service. Memory floor: 96 MB (measured floor rounded up to the next multiple of 32 MB). Status: Validated
What was measured?
- At 96 MB the health check, namespace and database creation, an upsert and a 500-row insert worked, and all 500 rows survived a forced stop and restart.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
- Below the floor, 80 MB booted but crashed on the first query and 64 MB panicked at boot.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
- Crash test: 16 writers, 3 forced-stop cycles, 0 acknowledged writes lost.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
- Scale to zero: the instance went to standby about 3 seconds after going idle; the first request after wake took 0.8 to 1.1 seconds from a distant client, with data intact over 3 cycles.Source: product test notes, probe date 2026-10-28, measured on the production microVM runtime. Method
| Engine | SurrealDB 3 (SurrealKV) |
|---|---|
| Category | Database |
| Memory floor | 96 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?
Heavier writes and queries were not probed at the floor; budget more for real use.
- Heavier writes, indexes and live queries were not probed at 96 MB.
- The gateway can return a 502 for a few seconds right after a restart.
A memory floor is not a sizing recommendation.
Where would it be used?
What else is in database?
Last updated