Single database vs all databases: PostgreSQL, MySQL, and MongoDB

A single-database backup answers a focused question: can this application database be rebuilt without replacing its neighbors? An all-databases backup answers a broader one: can the database server or instance be reconstructed with the shared objects that applications depend on? Neither scope is inherently safer. The correct choice follows the incident you need to survive.

Independent application databases benefit from independent recovery points, retention, access controls, and restore tests. One team's accidental table deletion should not require replaying an unrelated finance database. A server-wide copy becomes important when the host itself is the recovery unit, when shared identities are difficult to reproduce, or when several databases must move together. Many production designs need both: frequent application-level backups for routine recovery and a less frequent capture of global or server-level state.

Write the scope in operational language. “PostgreSQL cluster including roles and tablespaces,” “three named MySQL schemas plus routines and events,” and “full MongoDB replica-set dump including users and roles” are testable claims. “Full backup” is not, because each tool excludes or handles something differently.

PostgreSQL's pg_dump exports one database. Archive formats can be inspected, filtered, reordered, and restored in parallel with pg_restore, which makes this scope convenient for an application recovery or migration. The database archive does not include cluster-wide roles or tablespaces. Ownership and grants in the archive may refer to those roles, so a technically complete database dump can still fail or emerge with the wrong owners on a clean cluster.

pg_dumpall covers every database and emits global objects such as roles and tablespaces as a plain SQL script. It connects to the server once per database and usually needs broad privileges to read everything; restoring the full script also needs authority to create databases and roles. The result has a much larger blast radius than a pg_dump archive and lacks pg_restore's selective archive workflow.

A useful middle ground is one pg_dump archive per application database plus a separate pg_dumpall globals-only export. That preserves selective, potentially parallel database recovery while retaining the identities and tablespace definitions needed for a cluster rebuild. The two artifact types must remain associated in inventory, and tablespace directories must exist before a cluster-level restore uses them. Test ownership and extension creation on a clean target rather than simply checking that both files are non-empty.

mysqldump can export one schema, several named schemas, or all databases. When several databases are selected with the databases mode, the output includes database creation and selection statements, which changes restore behavior compared with importing a dump into an already chosen schema. A server-wide dump can also include the mysql system schema, bringing accounts and privileges into a recovery that may otherwise have been application-only.

Object defaults matter. Triggers are included with their tables by default, while stored routines and scheduled events require deliberate coverage. MySQL 8.4 makes that distinction especially important for all-databases exports: routines and events are stored in data-dictionary tables that mysqldump does not export, so the documentation requires their options explicitly. The all-databases name also does not mean every internal schema and every server setting. INFORMATION_SCHEMA is not dumped, and performance_schema and sys are excluded by default.

Consistency across InnoDB data depends on the selected transactional and locking behavior, while non-transactional tables remain a separate concern. A larger scope increases runtime and the chance of encountering an unusual engine, missing privilege, or DDL operation. If applications are operationally independent, separate dumps make failures and restores easier to isolate. Pair them with a documented method for users, grants, routines, events, and any binary logs required for point-in-time recovery.

mongodump exports every database in an instance when no database is selected. A database-scoped dump narrows the artifact, but it also changes the treatment of users and roles. MongoDB documents that an instance-wide dump includes user and role definitions, whereas a database-specific dump needs explicit user-and-role coverage when those identities must travel with it. Authentication source and backup scope are related but not identical: the database holding a user's credentials may differ from the database being exported.

The consistency tradeoff is sharper than a simple size comparison. Without oplog capture, writes during mongodump can leave the result representing more than one moment. Oplog-based capture is limited to a full dump of a replica-set member; MongoDB does not allow it together with a database or collection filter, and it does not provide the same mechanism for a full sharded-cluster dump through mongos. A team choosing a small, database-only artifact may therefore be accepting weaker cross-collection timing guarantees during live writes.

An instance-wide dump is not automatically a sharded-cluster recovery plan. Shards, config servers, cluster metadata, balancer behavior, and the supported backup procedure for the topology still matter. Large mongodump operations can also displace the working set and affect production performance. For Atlas or a complex self-managed cluster, compare logical dumps with the provider or topology-specific backup mechanism before treating “all databases” as complete.

A backup identity should be able to read exactly the promised scope and no more. Single-database exports often support narrower database-level privileges. Server-wide operations tend to require global visibility, access to system metadata, or superuser-like authority. PostgreSQL's pg_dumpall commonly needs a database superuser for a complete export; MongoDB offers backup roles at the administrative level; MySQL object coverage can require privileges beyond selecting table rows.

The archive inherits the sensitivity of everything it contains. A server-wide dump may combine customer datasets, password-verifier data, role definitions, and internal schema details in one object. That affects encryption, storage credentials, retention, audit access, and who may perform a restore rehearsal. Separate application backups can reduce the audience and blast radius, provided global dependencies are not forgotten. Do not grant a central backup account broad access merely because it makes configuration shorter; document why each privilege exists and alert when the expected scope cannot be read.

Single-database recovery is usually easier to isolate. It can target a newly named database or a separate instance, and validation can focus on one application's schema and invariants. Even then, collisions involving owners, definers, extensions, users, or existing collections can surprise the operator. A selective restore is not automatically non-destructive; the destination and tool options determine what is replaced.

Server-wide restore is closer to rebuilding an authority boundary. PostgreSQL scripts can create roles, tablespaces, and databases. MySQL system-schema content can affect accounts and grants. MongoDB instance dumps can carry user and role definitions. Test these artifacts in an empty, access-controlled environment first, then review exactly which objects would be introduced or overwritten. Avoid using a shared staging database where “temporary” global objects can affect other teams.

Recovery time may reverse an intuitive choice. One very large all-databases SQL file is operationally simple to retain but slow to inspect, replay, and partially recover. Separate archives can restore in parallel and let the most important service return first, yet they create more scheduling, inventory, and global-object coordination. Measure both storage and restore work before standardizing on one scope.

For a shared PostgreSQL or MySQL server, protect each critical application database on a schedule aligned with its own recovery point objective. Add a server-level inventory or global-object backup on a schedule appropriate to identity and configuration changes. For MongoDB, choose between database-scoped logical dumps and a full topology-aware method based on consistency needs; do not force the same pattern onto a replica set and a sharded cluster.

Every recovery point should name its engine, source instance, scope, completion time, object coverage, consistency guarantee, and companion artifacts. Restore tests should alternate between the common case and the catastrophe: recover one application without touching its neighbors, then rebuild an empty server or instance with identities and shared objects. That pair of exercises reveals whether the two layers genuinely meet in the middle.

Revisit the boundary when an application adds a second database, starts sharing users, adopts cross-database jobs, or moves to a different topology. Backup scope is architecture that happens to run on a schedule. When the architecture changes, the old artifact may continue succeeding while protecting the wrong recovery unit.