Determine browser WASM memory limits and stabilise in-memory database #7

New issue

Open

opened 2026-08-07 14:22:12 +00:00 by hum3 · 0 comments

hum3 commented

2026-08-07 14:22:12 +00:00

Owner

Goal

Find the practical memory ceiling for go-postgres running in-browser via WASM, then demonstrate:

Crash: Running out of memory with unbounded growth (discovery mode)
Stability: Controlling memory to sustain operations indefinitely (sustained mode)

Context

go-postgres runs SQLite compiled to WASM (via ncruces/go-sqlite3). In-browser, memory is constrained by:

Browser per-tab memory limits (varies: Chrome ~4GB, Firefox ~4GB, Safari ~1-2GB)
debug.SetMemoryLimit(900MB) set by memcheck package init
WASM linear memory growth behaviour (can only grow, never shrink)

The soak testing infrastructure (task/WTstable branch, #6) provides the tools:

task soak:wasm — builds WASM binary and serves test UI
Discovery mode: no deletion, runs until OOM
Sustained mode: prunes oldest transactions when threshold exceeded

Tasks

Run discovery mode in Chrome, Firefox, Safari — record max Alloc before crash
Determine safe operating ceiling per browser (e.g. 70% of crash point)
Run sustained mode with threshold set below ceiling — confirm indefinite operation
Document results in research-soak-testing.md
Consider whether TranslateCached() should be wired into the driver by default to reduce allocation pressure in WASM
Test with gobank's actual workload patterns (not just synthetic soak)

Expected Outcomes

A table of browser memory limits (crash point and safe ceiling)
Proof that sustained mode runs indefinitely below the ceiling
Recommendation for default delete/prune thresholds in WASM environments

#6 Stability/soak testing infrastructure
gobank#6 Refactor memory checker to use go-postgres/memcheck

Migrated from Codeberg: originally #7, opened 2026-03-20.

## Goal Find the practical memory ceiling for go-postgres running in-browser via WASM, then demonstrate: 1. **Crash**: Running out of memory with unbounded growth (discovery mode) 2. **Stability**: Controlling memory to sustain operations indefinitely (sustained mode) ## Context go-postgres runs SQLite compiled to WASM (via ncruces/go-sqlite3). In-browser, memory is constrained by: - Browser per-tab memory limits (varies: Chrome ~4GB, Firefox ~4GB, Safari ~1-2GB) - `debug.SetMemoryLimit(900MB)` set by `memcheck` package init - WASM linear memory growth behaviour (can only grow, never shrink) The soak testing infrastructure (task/WTstable branch, #6) provides the tools: - `task soak:wasm` — builds WASM binary and serves test UI - Discovery mode: no deletion, runs until OOM - Sustained mode: prunes oldest transactions when threshold exceeded ## Tasks - [ ] Run discovery mode in Chrome, Firefox, Safari — record max Alloc before crash - [ ] Determine safe operating ceiling per browser (e.g. 70% of crash point) - [ ] Run sustained mode with threshold set below ceiling — confirm indefinite operation - [ ] Document results in `research-soak-testing.md` - [ ] Consider whether `TranslateCached()` should be wired into the driver by default to reduce allocation pressure in WASM - [ ] Test with gobank's actual workload patterns (not just synthetic soak) ## Expected Outcomes - A table of browser memory limits (crash point and safe ceiling) - Proof that sustained mode runs indefinitely below the ceiling - Recommendation for default delete/prune thresholds in WASM environments ## Related - #6 Stability/soak testing infrastructure - gobank#6 Refactor memory checker to use go-postgres/memcheck --- *Migrated from Codeberg: originally [#7](https://codeberg.org/hum3/go-postgres/issues/7), opened 2026-03-20.*

No labels

OnDemand

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

hum3/go-postgres#7

No description provided.

Rows
Columns