A D1 database with full-text search can now be exported without first removing its virtual tables. The catch is the destination: Cloudflare’s November 12, 2026 announcement says the new dump targets the SQLite CLI and cannot be imported back into D1.

AI disclosure: This article was generated with AI assistance from public sources. The archive fixture and verification steps below are proposed examples, not reported Cloudflare tests or an implementation in Keith’s projects.

That distinction belongs in the export job’s name and its acceptance criteria. “A local copy for inspection” and “a file that can rebuild the hosted application” are different deliverables. A successful export establishes neither one until someone exercises the intended destination.

Make the compatibility choice explicit

Cloudflare now supports exporting databases containing virtual tables, including FTS5 full-text search and R*Tree spatial indexes. The announcement specifies dump_options.compatibility set to sqlite3_cli_only in the export API, with the same compatibility option exposed through wrangler d1 export.

The option identifies an execution target. Do not infer a D1 round trip from the file’s SQL extension.

For a proposed archive workflow, I would put the source database identifier, export time, schema revision, compatibility mode, and intended destination beside the artifact. Keep the export result and any import errors with that record. A teammate opening the folder should not have to reconstruct what “latest-backup.sql” was meant to support.

This is also a useful place to name the separate D1 recovery procedure and its owner. A local inspection copy can be valuable without being the artifact that procedure consumes.

Preserve what makes a search result useful

The public Illumia Archive Intelligence case study describes a local PostgreSQL application that preserves original service records and the relationship between parent cases and child work entries. Search results group matching work records under their parent cases. The browser and bounded Claude Desktop tools use the same retrieval service.

The implementation was tested with synthetic records; workplace acceptance was staged separately. Illumia is not documented as a D1 deployment.

Its retrieval design supplies a concrete acceptance question for a hypothetical D1 archive: after exporting to a local SQLite environment, can an operator still find the relevant work note inside the right case history?

Counting case rows cannot answer that. A copied table may contain the expected case count while a retrieval query, note relationship, or application mapping is wrong. Testing the restored search path makes those differences visible.

Use a fixture whose answer you already know

Start with a small synthetic archive in a disposable environment. Give one case a title that does not contain the search term. Put a distinctive phrase only in a child work note. Give a second case a similar title, but a different note.

Before export, record the expected case ID and matching note ID for the chosen query. Then export using the documented compatibility mode and load the dump with its declared SQLite CLI target in a clean local environment. Record the actual tool version and any errors.

Run the corresponding local search and inspect the returned identifiers. The useful check is whether the known note leads to the intended parent case, with the surrounding history still inspectable. A nonempty result list would be too weak.

Keep the test query’s semantics explicit. Literal matching, token-based full-text search, and an application’s combined filters need not mean the same thing. Compare the behavior the application promises rather than assuming two search implementations share an identical interpretation of every query.

If an application adapter is part of the local inspection plan, test through that adapter too. Direct SQL success cannot establish that a user interface maps a matching note to the correct case.

These are proposed checks for this fixture, not a claim that Cloudflare’s export corrupts records or that a small fixture validates a full archive.

Decide whether the copy is a snapshot or a working database

An inspection snapshot and a database intended for continued edits have different requirements. If the exported copy is meant to remain read-only, say so and preserve an untouched copy of the artifact.

If the intended local tool will accept changes, use a separate disposable copy for an additional exercise: change the distinctive phrase through the intended write path. Confirm that search finds the new phrase and handles the old one according to the documented search behavior. That tests the destination’s ongoing search maintenance, not just its initial contents.

The distinction matters for archive and support tools. An engineer investigating an incident may need a faithful point-in-time copy. A team continuing work locally needs a functioning write-and-search workflow as well. Neither goal is established by a file download alone.

Cloudflare’s new option removes an export limitation for virtual-table databases. Teams can make that useful by naming the supported destination, checking a known retrieval result there, and keeping the hosted recovery path explicit.

Before labeling the job complete, have another maintainer use the artifact for the task it promises.