{"article":{"slug":"persistent-databases-in-the-browser-with-duckdb-wasm-and-opfs","title":"Persistent Databases in the Browser with DuckDB-Wasm and OPFS","subtitle":null,"summary":"DuckDB explains how DuckDB-Wasm can open a persistent database file in the browser’s Origin Private File System (OPFS), when data reaches disk, and how that changes browser analytics apps that previously relied on Parquet-in-IndexedDB workarounds.","content_type":"blog_post","language":"en","canonical_url":"https://duckdb.org/2026/09/18/opfs-wasm","author":{"name":"Carlo Piovesan, Geertjan Wielenga","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"DuckDB","url":"https://duckdb.org","listing_slug":null,"listing":null},"topics":[{"name":"Databases","slug":"databases","url":"https://listedarticles.com/topics/databases"},{"name":"Web Development","slug":"web-development","url":"https://listedarticles.com/topics/web-development"},{"name":"Open Source","slug":"open-source","url":"https://listedarticles.com/topics/open-source"},{"name":"Performance","slug":"performance","url":"https://listedarticles.com/topics/performance"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1800,"reading_minutes":8,"published_at":"2026-09-18T00:00:00.000Z","added_at":"2026-09-19T21:09:25.566Z","updated_at":"2026-09-19T21:09:25.566Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":false},"profile_url":"https://listedarticles.com/articles/persistent-databases-in-the-browser-with-duckdb-wasm-and-opfs","markdown_url":"https://listedarticles.com/articles/persistent-databases-in-the-browser-with-duckdb-wasm-and-opfs.md","example":false,"citation":"Carlo Piovesan, Geertjan Wielenga, DuckDB. \"Persistent Databases in the Browser with DuckDB-Wasm and OPFS.\" 18 Sept 2026. https://duckdb.org/2026/09/18/opfs-wasm (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://duckdb.org/2026/09/18/opfs-wasm"},"body_markdown":"# Persistent Databases in the Browser with DuckDB-Wasm and OPFS\n\nCarlo Piovesan, Geertjan Wielenga\n\n2026-09-18 | 9 min\n\n_TL;DR: DuckDB-Wasm can open a persistent database file in the browser's Origin Private File System (OPFS). This post shows how, and when data reaches disk._\n\nWhen [DuckDB-Wasm was launched]() in 2021, databases could not be persisted: everything lived in the Wasm heap and vanished when the tab closed. Keeping data meant serializing tables to Parquet, storing the bytes in IndexedDB, and re-registering them on the next page load. This was doable, but had to be handled at the application layer and was not offered out of the box by DuckDB-Wasm.\n\nModern browsers (since [March 2023]()) now ship the [Origin Private File System (OPFS)](), a per-origin, sandboxed file system with random-access reads and writes. DuckDB-Wasm (tested with versions 1.32.0 and 1.33.1-dev64.0) can use it as a storage backend, as described in the [DuckDB documentation](): a database opened at an `opfs://` path survives reloads and browser restarts.\n\nThe following call opens a database file in OPFS:\n \n \n await db.open({\n path: 'opfs://analytics.duckdb',\n accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n });\n \n\nThe result is a regular `.duckdb` file with a write-ahead log and checkpoints that survives page reloads and browser restarts.\n\n> Note: at the time of writing, the build that npm serves as `latest` (1.33.1-dev57.0) creates the OPFS files but never writes to them, so nothing persists. It canonicalizes the path to `opfs:/analytics.duckdb` with a single slash, which no longer matches the OPFS handle. Pin 1.32.0 or use the `next` tag (1.33.1-dev64.0 or later).\n\n## Opening a Database\n\nThe setup is the same as for any DuckDB-Wasm application: pick a bundle, start a worker, instantiate the database. The only new part is the `open` call, marked below. The import resolves to whichever version is installed, and `getJsDelivrBundles()` fetches the matching worker and `.wasm` files, so install a version that persists correctly: `npm install @duckdb/[[email protected]]()` or `@next`.\n \n \n import * as duckdb from '@duckdb/duckdb-wasm';\n \n const bundles = duckdb.getJsDelivrBundles();\n const bundle = await duckdb.selectBundle(bundles);\n \n // Worker scripts must be same-origin, so wrap the CDN worker URL in a Blob\n const workerUrl = URL.createObjectURL(\n new Blob([`importScripts(\"${bundle.mainWorker}\");`], {\n type: 'text/javascript'\n })\n );\n const worker = new Worker(workerUrl);\n const db = new duckdb.AsyncDuckDB(new duckdb.ConsoleLogger(), worker);\n await db.instantiate(bundle.mainModule, bundle.pthreadWorker);\n URL.revokeObjectURL(workerUrl);\n \n // NEW: open a persistent database in OPFS instead of the default :memory:\n await db.open({\n path: 'opfs://analytics.duckdb',\n accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n });\n \n const conn = await db.connect();\n await conn.query(`\n CREATE TABLE IF NOT EXISTS transactions (\n id BIGINT,\n ts TIMESTAMP,\n merchant VARCHAR,\n category VARCHAR,\n amount DECIMAL(10, 2)\n );\n `);\n \n await conn.query(`INSERT INTO transactions VALUES (1, now(), 'Coolblue', 'electronics', 49.95)`);\n await conn.query('CHECKPOINT');\n \n const result = await conn.query('SELECT count(*) AS n FROM transactions');\n console.log(result.toArray()[0].n);\n \n\nReload the page and run the same code. The `CREATE TABLE IF NOT EXISTS` statement finds the existing table and does nothing, the insert adds a second row, and the count prints 2. There is no sync step, no export, no `localStorage` key to remember. The `opfs://` prefix tells DuckDB-Wasm's file system layer to resolve the path against the origin's private file system instead of the in-memory Emscripten file system.\n\nOpening the database creates the database file and its `.wal` in OPFS. Builds from 1.33.1-dev64.0 onward also create two empty helper files, `.wal.checkpoint` and `.wal.recovery`, that DuckDB uses during checkpointing. The `.duckdb` file is a regular DuckDB database file. If you pull it out of OPFS (shown below) and open it with the CLI or the Python client, it works.\n\n### Data Files\n\nThe same prefix works for data files. A common pattern is to load a remote dataset once, keep it in the persistent database, and cache derived results as Parquet files in OPFS. The example below uses the TPC-H `orders` table (scale factor 0.01, about 1,500 rows) that the [DuckDB web shell]() serves:\n \n \n await conn.query(`\n CREATE TABLE IF NOT EXISTS orders AS\n SELECT * FROM 'https://shell.duckdb.org/data/tpch/0_01/parquet/orders.parquet';\n `);\n await conn.query('CHECKPOINT');\n \n\nDuckDB-Wasm reads the remote file with HTTP range requests. Because the table is created with `IF NOT EXISTS`, the file is fetched only on the first page load; on later loads the table comes from OPFS and no request goes to `shell.duckdb.org`. You can see this in the browser's Network tab, which lists the range requests on the first load and stays quiet afterwards, or in DuckDB-Wasm's own logs: the `ConsoleLogger` passed to `AsyncDuckDB` records each HTTP read, so the absence of those log lines on a reload confirms the data is served entirely from OPFS.\n\nWith the data local, an aggregation can be written to a Parquet file in OPFS and read back later:\n \n \n COPY (\n SELECT o_orderpriority AS priority,\n date_trunc('month', o_orderdate) AS month,\n sum(o_totalprice) AS total\n FROM orders\n GROUP BY ALL\n ) TO 'opfs://cache/monthly_totals.parquet';\n \n SELECT * FROM 'opfs://cache/monthly_totals.parquet';\n \n\nNested directories such as `cache/` are created on demand. OPFS files are ordinary DuckDB file paths, so globbing, `read_csv` and the other readers work as usual. Reading and writing `opfs://` paths from SQL needs one extra option on `open()`, described next.\n\n### File Handling Modes\n\nWith `opfs: { fileHandling: 'auto' }`, DuckDB-Wasm scans each statement for single-quoted `'opfs://...'` literals, registers those files before execution (creating them and any missing directories if needed) and drops the handles afterwards. The option only takes effect when the database itself was opened from an `opfs://` path. Without it, every file other than the database has to be registered by hand:\n \n \n // Option 1: automatic registration of opfs:// paths found in SQL\n await db.open({\n path: 'opfs://analytics.duckdb',\n accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n opfs: { fileHandling: 'auto' },\n });\n \n // Option 2: manual registration (the default)\n await db.open({\n path: 'opfs://analytics.duckdb',\n accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n });\n await db.registerOPFSFileName('opfs://cache/monthly_totals.parquet');\n // ... run queries against it ...\n await db.dropFile('opfs://cache/monthly_totals.parquet');\n \n\nAutomatic mode is convenient for one-off reads. Manual mode requires more code but avoids re-acquiring an OPFS access handle on every statement, which adds up for applications that run many small queries. A file can be held by only one handle at a time, so the DuckDB documentation recommends [dropping registered files]() with `db.dropFile()` before another connection or database instance opens them.\n\n## Durability\n\nDuckDB-Wasm writes to OPFS the same way native DuckDB writes to a local disk: through a write-ahead log and periodic checkpoints. What differs is that a browser tab is rarely closed cleanly, so the defaults that work on a desktop can leave you with a slow reopen.\n\nDuckDB uses a [write-ahead log](). Committed transactions are appended to `analytics.duckdb.wal` first. The main file is updated at _checkpoint_ time. A checkpoint happens automatically when the WAL grows past `checkpoint_threshold` (16 MB by default), when the database is closed cleanly, or when you run `CHECKPOINT` yourself.\n\nIn a desktop process, \"closed cleanly\" is the common case. In a browser tab, it is not: the user closes the tab, the phone kills the background page, the laptop lid goes down. None of these run your shutdown code reliably. Two rules follow from that.\n\n**Call`CHECKPOINT` after writes you cannot afford to lose.** The [DuckDB documentation]() is explicit about this: writes are flushed to OPFS by `CHECKPOINT`. Committed transactions are appended to the WAL, and DuckDB replays the WAL on the next open, but a browser tab can be terminated at any point, so a checkpoint is the only way to be certain that the data is in the main file.\n\n**Checkpoint per batch, not per statement.** A large WAL also makes the _next_ open slower, because replay has to happen before the first query. For an interactive app, checkpointing after each batch of user edits keeps both the data safe and the reopen fast:\n \n \n await conn.query('INSERT INTO transactions VALUES (...)');\n await conn.query('CHECKPOINT');\n \n\nIf you would rather not track batches, set the checkpoint threshold to zero once after connecting. DuckDB then checkpoints after every statement, which costs some write throughput but removes the question entirely:\n \n \n await conn.query(`SET checkpoint_threshold = '0KB'`);\n \n\nA clean shutdown looks like this:\n \n \n await conn.query('CHECKPOINT');\n await conn.close();\n await db.terminate();\n \n\nWhat happens when a tab is killed mid-transaction, and how to share one database between tabs, are covered in a follow-up post.\n\nThere is a second kind of durability to keep in mind, one that sits below DuckDB. OPFS is browser storage, not a hard guarantee. The browser can evict it when disk space runs low or when the origin has not been visited for a long time, and the user can clear it from the site's settings. Treat OPFS as a fast local cache for accelerating startup and persisting working state, not as your only copy of data you cannot lose. For durable storage, keep the source of truth somewhere stable and sync back to it: a [DuckLake]() catalog, or plain files on object storage through `s3://` paths.\n\n## Export\n\nUsers will want to move their data to another device, back it up, or open it with a different tool. DuckDB-Wasm itself [cannot move files into or out of OPFS]() yet, but the database is a plain DuckDB file and the browser's OPFS API lets you read it back as bytes:\n \n \n await conn.query('CHECKPOINT');\n const root = await navigator.storage.getDirectory();\n const handle = await root.getFileHandle('analytics.duckdb');\n const file = await handle.getFile();\n // Offer as a download, upload to your backend, etc.\n const url = URL.createObjectURL(file);\n \n\nOr export from SQL to Parquet:\n \n \n COPY transactions\n TO 'opfs://export/transactions.parquet'\n (FORMAT parquet, COMPRESSION zstd);\n \n\nCombined with [DuckDB's Parquet support](), this allows preparing and cleaning data in the browser before uploading it to a server. And because the on-disk format is standard, the reverse works too: ship a pre-built `.duckdb` file with your app, copy it into OPFS on first launch, and open it. Users get a local dataset without an import step.\n\n## Conclusion\n\nLack of persistence was the main limitation of DuckDB-Wasm for a long time. With OPFS, DuckDB-Wasm can open a database file in the browser, commit transactions to a WAL, checkpoint, and reopen the same database after a reload. Three things make it work well: run `CHECKPOINT` after each batch of writes rather than after every statement, give users a way to download the database file, and read the [limitations listed in the DuckDB documentation]() before shipping: one handle per file, and renames from SQL only work between two already-registered OPFS files.\n\nWith this, a local-first application no longer needs a server, IndexedDB wrapper, or custom serialization to keep analytical data between sessions. Try it in your own application, and share what you build on [GitHub]() or [Discord]().\n\n##### In this article\n\n * Opening a Database\n * Data Files\n * File Handling Modes\n * Durability\n * Export\n * Conclusion\n\n## Recent posts \n\n[ All blog posts ]()\n\n[]( \"DuckDB Skills for Claude Code\")\n\n### DuckDB Skills for Claude Code\n\n2026-09-16\n\n4 min\n\nThe DuckDB team\n\n[]( \"Try DuckDB v2.0-alpha\")\n\n### Try DuckDB v2.0-alpha\n\n2026-09-02\n\n2 min\n\nThe DuckDB team\n\n[]( \"DuckLabs to Join AWS, Projects to Remain Open Source\")\n\n### DuckLabs to Join AWS, Projects to Remain Open Source\n\n2026-08-26\n\n1 min\n\nMark Raasveldt and Hannes Mühleisen","body_html":"

Persistent Databases in the Browser with DuckDB-Wasm and OPFS

\n

Carlo Piovesan, Geertjan Wielenga

\n

2026-09-18 | 9 min

\n

TL;DR: DuckDB-Wasm can open a persistent database file in the browser's Origin Private File System (OPFS). This post shows how, and when data reaches disk.

\n

When DuckDB-Wasm was launched in 2021, databases could not be persisted: everything lived in the Wasm heap and vanished when the tab closed. Keeping data meant serializing tables to Parquet, storing the bytes in IndexedDB, and re-registering them on the next page load. This was doable, but had to be handled at the application layer and was not offered out of the box by DuckDB-Wasm.

\n

Modern browsers (since March 2023) now ship the Origin Private File System (OPFS), a per-origin, sandboxed file system with random-access reads and writes. DuckDB-Wasm (tested with versions 1.32.0 and 1.33.1-dev64.0) can use it as a storage backend, as described in the DuckDB documentation: a database opened at an opfs:// path survives reloads and browser restarts.

\n

The following call opens a database file in OPFS:

\n
await db.open({\n    path: 'opfs://analytics.duckdb',\n    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n});
\n

The result is a regular .duckdb file with a write-ahead log and checkpoints that survives page reloads and browser restarts.

\n

Note: at the time of writing, the build that npm serves as latest (1.33.1-dev57.0) creates the OPFS files but never writes to them, so nothing persists. It canonicalizes the path to opfs:/analytics.duckdb with a single slash, which no longer matches the OPFS handle. Pin 1.32.0 or use the next tag (1.33.1-dev64.0 or later).

\n

Opening a Database

\n

The setup is the same as for any DuckDB-Wasm application: pick a bundle, start a worker, instantiate the database. The only new part is the open call, marked below. The import resolves to whichever version is installed, and getJsDelivrBundles() fetches the matching worker and .wasm files, so install a version that persists correctly: npm install @duckdb/[[email protected]](</cdn-cgi/l/email-protection>) or @next.

\n
import * as duckdb from '@duckdb/duckdb-wasm';\n\nconst bundles = duckdb.getJsDelivrBundles();\nconst bundle = await duckdb.selectBundle(bundles);\n\n// Worker scripts must be same-origin, so wrap the CDN worker URL in a Blob\nconst workerUrl = URL.createObjectURL(\n    new Blob([`importScripts("${bundle.mainWorker}");`], {\n        type: 'text/javascript'\n    })\n);\nconst worker = new Worker(workerUrl);\nconst db = new duckdb.AsyncDuckDB(new duckdb.ConsoleLogger(), worker);\nawait db.instantiate(bundle.mainModule, bundle.pthreadWorker);\nURL.revokeObjectURL(workerUrl);\n\n// NEW: open a persistent database in OPFS instead of the default :memory:\nawait db.open({\n    path: 'opfs://analytics.duckdb',\n    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n});\n\nconst conn = await db.connect();\nawait conn.query(`\n    CREATE TABLE IF NOT EXISTS transactions (\n        id BIGINT,\n        ts TIMESTAMP,\n        merchant VARCHAR,\n        category VARCHAR,\n        amount DECIMAL(10, 2)\n    );\n`);\n\nawait conn.query(`INSERT INTO transactions VALUES (1, now(), 'Coolblue', 'electronics', 49.95)`);\nawait conn.query('CHECKPOINT');\n\nconst result = await conn.query('SELECT count(*) AS n FROM transactions');\nconsole.log(result.toArray()[0].n);
\n

Reload the page and run the same code. The CREATE TABLE IF NOT EXISTS statement finds the existing table and does nothing, the insert adds a second row, and the count prints 2. There is no sync step, no export, no localStorage key to remember. The opfs:// prefix tells DuckDB-Wasm's file system layer to resolve the path against the origin's private file system instead of the in-memory Emscripten file system.

\n

Opening the database creates the database file and its .wal in OPFS. Builds from 1.33.1-dev64.0 onward also create two empty helper files, .wal.checkpoint and .wal.recovery, that DuckDB uses during checkpointing. The .duckdb file is a regular DuckDB database file. If you pull it out of OPFS (shown below) and open it with the CLI or the Python client, it works.

\n

Data Files

\n

The same prefix works for data files. A common pattern is to load a remote dataset once, keep it in the persistent database, and cache derived results as Parquet files in OPFS. The example below uses the TPC-H orders table (scale factor 0.01, about 1,500 rows) that the DuckDB web shell serves:

\n
await conn.query(`\n    CREATE TABLE IF NOT EXISTS orders AS\n    SELECT * FROM 'https://shell.duckdb.org/data/tpch/0_01/parquet/orders.parquet';\n`);\nawait conn.query('CHECKPOINT');
\n

DuckDB-Wasm reads the remote file with HTTP range requests. Because the table is created with IF NOT EXISTS, the file is fetched only on the first page load; on later loads the table comes from OPFS and no request goes to shell.duckdb.org. You can see this in the browser's Network tab, which lists the range requests on the first load and stays quiet afterwards, or in DuckDB-Wasm's own logs: the ConsoleLogger passed to AsyncDuckDB records each HTTP read, so the absence of those log lines on a reload confirms the data is served entirely from OPFS.

\n

With the data local, an aggregation can be written to a Parquet file in OPFS and read back later:

\n
COPY (\n    SELECT o_orderpriority AS priority,\n           date_trunc('month', o_orderdate) AS month,\n           sum(o_totalprice) AS total\n    FROM orders\n    GROUP BY ALL\n) TO 'opfs://cache/monthly_totals.parquet';\n\nSELECT * FROM 'opfs://cache/monthly_totals.parquet';
\n

Nested directories such as cache/ are created on demand. OPFS files are ordinary DuckDB file paths, so globbing, read_csv and the other readers work as usual. Reading and writing opfs:// paths from SQL needs one extra option on open(), described next.

\n

File Handling Modes

\n

With opfs: { fileHandling: 'auto' }, DuckDB-Wasm scans each statement for single-quoted 'opfs://...' literals, registers those files before execution (creating them and any missing directories if needed) and drops the handles afterwards. The option only takes effect when the database itself was opened from an opfs:// path. Without it, every file other than the database has to be registered by hand:

\n
// Option 1: automatic registration of opfs:// paths found in SQL\nawait db.open({\n    path: 'opfs://analytics.duckdb',\n    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n    opfs: { fileHandling: 'auto' },\n});\n\n// Option 2: manual registration (the default)\nawait db.open({\n    path: 'opfs://analytics.duckdb',\n    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,\n});\nawait db.registerOPFSFileName('opfs://cache/monthly_totals.parquet');\n// ... run queries against it ...\nawait db.dropFile('opfs://cache/monthly_totals.parquet');
\n

Automatic mode is convenient for one-off reads. Manual mode requires more code but avoids re-acquiring an OPFS access handle on every statement, which adds up for applications that run many small queries. A file can be held by only one handle at a time, so the DuckDB documentation recommends dropping registered files with db.dropFile() before another connection or database instance opens them.

\n

Durability

\n

DuckDB-Wasm writes to OPFS the same way native DuckDB writes to a local disk: through a write-ahead log and periodic checkpoints. What differs is that a browser tab is rarely closed cleanly, so the defaults that work on a desktop can leave you with a slow reopen.

\n

DuckDB uses a write-ahead log. Committed transactions are appended to analytics.duckdb.wal first. The main file is updated at checkpoint time. A checkpoint happens automatically when the WAL grows past checkpoint_threshold (16 MB by default), when the database is closed cleanly, or when you run CHECKPOINT yourself.

\n

In a desktop process, "closed cleanly" is the common case. In a browser tab, it is not: the user closes the tab, the phone kills the background page, the laptop lid goes down. None of these run your shutdown code reliably. Two rules follow from that.

\n

CallCHECKPOINT after writes you cannot afford to lose. The DuckDB documentation is explicit about this: writes are flushed to OPFS by CHECKPOINT. Committed transactions are appended to the WAL, and DuckDB replays the WAL on the next open, but a browser tab can be terminated at any point, so a checkpoint is the only way to be certain that the data is in the main file.

\n

Checkpoint per batch, not per statement. A large WAL also makes the next open slower, because replay has to happen before the first query. For an interactive app, checkpointing after each batch of user edits keeps both the data safe and the reopen fast:

\n
await conn.query('INSERT INTO transactions VALUES (...)');\nawait conn.query('CHECKPOINT');
\n

If you would rather not track batches, set the checkpoint threshold to zero once after connecting. DuckDB then checkpoints after every statement, which costs some write throughput but removes the question entirely:

\n
await conn.query(`SET checkpoint_threshold = '0KB'`);
\n

A clean shutdown looks like this:

\n
await conn.query('CHECKPOINT');\nawait conn.close();\nawait db.terminate();
\n

What happens when a tab is killed mid-transaction, and how to share one database between tabs, are covered in a follow-up post.

\n

There is a second kind of durability to keep in mind, one that sits below DuckDB. OPFS is browser storage, not a hard guarantee. The browser can evict it when disk space runs low or when the origin has not been visited for a long time, and the user can clear it from the site's settings. Treat OPFS as a fast local cache for accelerating startup and persisting working state, not as your only copy of data you cannot lose. For durable storage, keep the source of truth somewhere stable and sync back to it: a DuckLake catalog, or plain files on object storage through s3:// paths.

\n

Export

\n

Users will want to move their data to another device, back it up, or open it with a different tool. DuckDB-Wasm itself cannot move files into or out of OPFS yet, but the database is a plain DuckDB file and the browser's OPFS API lets you read it back as bytes:

\n
await conn.query('CHECKPOINT');\nconst root = await navigator.storage.getDirectory();\nconst handle = await root.getFileHandle('analytics.duckdb');\nconst file = await handle.getFile();\n// Offer as a download, upload to your backend, etc.\nconst url = URL.createObjectURL(file);
\n

Or export from SQL to Parquet:

\n
COPY transactions\nTO 'opfs://export/transactions.parquet'\n(FORMAT parquet, COMPRESSION zstd);
\n

Combined with DuckDB's Parquet support, this allows preparing and cleaning data in the browser before uploading it to a server. And because the on-disk format is standard, the reverse works too: ship a pre-built .duckdb file with your app, copy it into OPFS on first launch, and open it. Users get a local dataset without an import step.

\n

Conclusion

\n

Lack of persistence was the main limitation of DuckDB-Wasm for a long time. With OPFS, DuckDB-Wasm can open a database file in the browser, commit transactions to a WAL, checkpoint, and reopen the same database after a reload. Three things make it work well: run CHECKPOINT after each batch of writes rather than after every statement, give users a way to download the database file, and read the limitations listed in the DuckDB documentation before shipping: one handle per file, and renames from SQL only work between two already-registered OPFS files.

\n

With this, a local-first application no longer needs a server, IndexedDB wrapper, or custom serialization to keep analytical data between sessions. Try it in your own application, and share what you build on GitHub or Discord.

\n
In this article
\n
  • Opening a Database
    • Data Files
    • File Handling Modes
  • Durability
  • Export
  • Conclusion
\n

Recent posts

\n

All blog posts

\n

\n

DuckDB Skills for Claude Code

\n

2026-09-16

\n

4 min

\n

The DuckDB team

\n

\n

Try DuckDB v2.0-alpha

\n

2026-09-02

\n

2 min

\n

The DuckDB team

\n

\n

DuckLabs to Join AWS, Projects to Remain Open Source

\n

2026-08-26

\n

1 min

\n

Mark Raasveldt and Hannes Mühleisen

","headings":[{"level":1,"text":"Persistent Databases in the Browser with DuckDB-Wasm and OPFS","id":"persistent-databases-in-the-browser-with-duckdb-wasm-and-opfs"},{"level":2,"text":"Opening a Database","id":"opening-a-database"},{"level":3,"text":"Data Files","id":"data-files"},{"level":3,"text":"File Handling Modes","id":"file-handling-modes"},{"level":2,"text":"Durability","id":"durability"},{"level":2,"text":"Export","id":"export"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Recent posts","id":"recent-posts"},{"level":3,"text":"DuckDB Skills for Claude Code","id":"duckdb-skills-for-claude-code"},{"level":3,"text":"Try DuckDB v2.0-alpha","id":"try-duckdb-v2-0-alpha"},{"level":3,"text":"DuckLabs to Join AWS, Projects to Remain Open Source","id":"ducklabs-to-join-aws-projects-to-remain-open-source"}]}}