Supported commands

Query commands

Update Operators

The following operators and modifiers are available in the update and findAndModify commands.

Projection Operators

The following operators are available in the find command projection argument.

Query Plan Cache Commands

Free Monitoring Commands

Database Operations

User Management Commands

Authentication Commands

Role Management Commands

Replication Commands

FerretDB v1 (SQLite) presents itself as a single-node, always-primary replica set of one — enough for a MongoDB-wire client's oplog tailing (e.g. Meteor's OpLog mode), not real multi-node replication or elections. See the CHANGELOG for details.

Session Commands

Related issue.

Related issue.

Aggregation pipelines

Related issue.

Aggregation pipeline stages

Aggregation pipeline operators

Administration commands

Diagnostic commands

FerretDB v1 extension commands

These commands are specific to this FerretDB v1 (SQLite) build and are not part of the MongoDB command set.

throttle

A self-throttle for host-CPU pressure. A client that shares the host with FerretDB can call throttle to (1) learn how busy FerretDB is and (2) ask it to slow down when the host CPU is high (a client cannot pause FerretDB's internal work from the outside). While the throttle is active, every command sleeps slowDownMs before it runs, which lowers FerretDB's CPU use and yields time to other software on the host. The throttle self-expires after durationMs, so a crashed or disconnected client can never leave FerretDB permanently slow. The throttle command itself and the cheap health/handshake commands (hello/isMaster/ping) are never throttled.

A client can drive the loop by calling throttle repeatedly with an increasing slowDownMs (e.g. doubling) while the host CPU stays high, and backing off once enough CPU is free. commandsProcessed and operationsSummary let the client see how busy FerretDB is and what it has been doing between calls.

FerretDB also self-regulates. A client that shares the host may be too starved of CPU to measure the load or even send the request. So a background loop in FerretDB samples the host's total CPU (from /proc/stat) every few seconds and, when it is too high, adds its OWN increasing delay before each command until CPU returns below a target — then backs off. The delay actually applied per command is the max of the client-requested slowDownMs and FerretDB's self-regulated delay, so the two cooperate and FerretDB never monopolizes the host even with no client. Self-regulation is tunable with FERRETDB_CPU_SELF_REGULATE (default on), FERRETDB_CPU_HIGH_PERCENT, FERRETDB_CPU_TARGET_PERCENT, FERRETDB_CPU_SLOWDOWN_MS, FERRETDB_CPU_SLOWDOWN_MAX_MS and FERRETDB_CPU_INTERVAL_MS; it is a no-op where /proc/stat is unreadable.

Parameters (all optional):

Response fields:

Example:

db.runCommand({ throttle: 1, slowDownMs: 5, durationMs: 2000 })
// { ok: 1, commandsProcessed: 128374, throttled: true, slowDownMs: 5, ... }

db.runCommand({ throttle: 1, durationMs: 0 }) // resume full speed immediately