Browser Support and Limitations

Browser Support & Limitations

Supported browsers

The latest two versions of Chrome, Edge, Firefox and Safari on desktop. Phones and tablets work for small files, but the experience is designed for desktop screens.

Browser features Blinkql relies on

Feature	Used for	Support
WebAssembly	Running the DuckDB engine	All supported browsers
Web Workers	Keeping queries off the main thread	All supported browsers
Origin Private File System	Persisting datasets locally	Current versions of all major browsers
File System Access API	Native "open file" dialogs that remember files	Chromium-based browsers only; others fall back to a standard file picker
SharedArrayBuffer	Multithreaded engine (experimental, see ADR-007)	All supported browsers, when the page is cross-origin isolated
performance.measureUserAgentSpecificMemory	Memory benchmarks	Chromium-based browsers only, under cross-origin isolation

Known limitations

Memory. WebAssembly's 32-bit address space caps the engine's memory at 4 GB, and browsers or devices may allow less. Practical limits depend on your machine and the query. Benchmarks will turn this into concrete guidance. Until then:

• Prefer Parquet over CSV. It's compressed, columnar, and lets the engine read only the columns a query needs.
• Select the columns you need rather than SELECT *.
• Aggregate before exploring; use LIMIT when browsing raw rows.

Remote files. The host must send CORS headers that allow Blinkql's origin. For efficient Parquet reads it must also support HTTP range requests. Most object stores support both, but CORS usually has to be enabled on the bucket.

Cross-origin isolation side effects. COOP/COEP headers mean cross-origin resources embedded in the page must explicitly allow it. This affects embedding third-party content inside Blinkql. Blinkql itself can't be embedded in other sites: its Content Security Policy sets frame-ancestors 'none'.

Storage. Private browsing modes may restrict or clear persistent storage. Browsers can also evict site data under storage pressure unless persistence is granted, and Blinkql requests persistent storage (navigator.storage.persist()) the first time it keeps an imported file. Where files can't be kept (no OPFS, a private window, or a full quota), tables work for the visit and a notice says they will be gone after a reload.

Tips for large files

1. Convert CSV to Parquet once (Blinkql will offer this on import), then query the Parquet copy.
2. Close results you no longer need; each open result holds memory.
3. If the engine runs out of memory, Blinkql restarts it safely. Try narrowing the query with filters, fewer columns or aggregation.