Enabling write access

Every database you connect starts read-only. You can browse, query, script and export freely, and change nothing.

Enabling writes

Select the database in the sidebar and toggle Enable write access. That database — only that one — now accepts writes.

The setting is per database, not per project and not per account. Enabling writes on staging leaves production locked, because they are different databases.

Why it works this way

The most common way to damage a Firestore database is not malice. It is having two tabs open and editing the wrong one. A tool that is editable by default gives you no protection against that; a tool that is read-only by default makes it structurally impossible.

What the gate covers

The gate is enforced in the application core, where writes are actually issued — not in the interface. Every path is subject to it:

• Inline edits in the table
• The document editor
• Bulk updates, bulk deletes and find-and-replace
• Imports
• Scripts in the JavaScript editor
• Requests arriving through the MCP server

There is no exception carved out for automation. A script that calls db.doc(...).set(...) against a read-only database fails, the same as clicking a cell would.

Turning it back off

Toggle it off when you are done. A good habit on production databases: enable writes, make the change, turn it off again. The friction is the point.

Related

• Change history and undo — what happens after a write
• Bulk operations — the operations most worth gating