Supported engines

Backup runs the official command-line tools — pg_dump and mongodump — inside the isolated worker container, streaming their output through gzip directly to S3. Every backup is a full logical dump of the database in your connection string.

PostgreSQL

• Tool: pg_dump.
• Format: custom format (--format=custom) — the format pg_restore reads, with support for parallel restore.
• Portability flags: --no-owner --no-acl, so the dump restores cleanly into a database with a different role layout than the source.
• Archive name: postgres-full-<timestamp>-<suffix>.dump.gz.

Restore:

gunzip backup.dump.gz
pg_restore --dbname=postgres://user:pass@host:5432/target --jobs=4 backup.dump

The worker ships a current pg_dump (16-series); it connects to any server version the tool supports, which in practice covers all maintained PostgreSQL releases.

MongoDB

• Tool: mongodump.
• Format: archive (--archive) — a single-file BSON stream for mongorestore --archive. Replica sets and cluster URIs work; a Mongo dump can produce multiple files per job, all stored under the same backup prefix.
• Archive name: mongodb-full-<timestamp>-<suffix>.archive.gz.

Restore:

gunzip backup.archive.gz
mongorestore --uri mongodb://user:pass@host:27017 --archive=backup.archive

The worker ships MongoDB Database Tools 100.9.x, compatible with all maintained MongoDB server releases.

Compression

Archives are gzip-compressed in the streaming pipe between the dump tool and S3 — the size you see on a job is the compressed size, which is also what storage billing counts. Ratios depend on the data: text-heavy schemas compress well, opaque binary blobs barely at all. Gzip is currently the only compression mode.

Failure reporting

When a dump fails, the tool's stderr is classified into a human-readable summary before it's stored on the job — wrong password, version mismatch, permission denied, timeout, DNS failure, out of memory, disk full, TLS negotiation — so the job's error summary tells you what to fix without spelunking through raw tool output.

What's not supported

• Physical backups (pg_basebackup, Mongo filesystem snapshots)
• Point-in-time recovery / WAL archiving
• Per-table, per-collection, or schema-filtered dumps
• Custom pg_dump / mongodump flags

Reach out via app.norcube.com if one of these blocks your use case.

Database user requirements

Backup needs read access to everything you want dumped — for Postgres at minimum pg_read_all_data, for MongoDB the built-in read role on the target database. Ready-made role snippets: Manage credentials.