The final post in the advanced track combines four production topics that don't each need a full post but every working MongoDB engineer eventually faces: Kubernetes deployment via the new MongoDB Controllers for Kubernetes Operator (replacing the older Community + Enterprise operators), mongosync for cluster-to-cluster + multi-region active-active patterns, cost optimisation strategies for Atlas + self-hosted, and the compliance baselines (HIPAA, PCI-DSS, GDPR, SOC 2) every regulated workload needs.

Series map: 26 OpenTelemetry → 27 Geo → 28 Time-series extreme → 29 K8s + mongosync + cost + compliance (this post — final advanced).

Learning Outcome

  • Deploy MongoDB on Kubernetes with the modern MongoDB Controllers operator.
  • Use mongosync for cluster migration + multi-region sync.
  • Apply cost-optimisation playbooks for Atlas + self-hosted.
  • Architect for HIPAA, PCI-DSS, GDPR, SOC 2 baselines.

Part 1 — Kubernetes deployment

Chapter 1 — Operator choice in 2026

Three Kubernetes deployment options:

Option What When
MongoDB Controllers for Kubernetes Operator new unified operator (replaces older Community + Enterprise operators) new self-hosted on K8s
MongoDB Community Operator (older) Community editions; replica sets; basic ops existing self-hosted on K8s; small workloads
MongoDB Enterprise Operator (older, deprecated) Enterprise features + Ops Manager integration being migrated to Controllers operator
Percona Operator for MongoDB third-party; supports Community edition; sharding + backups + PITR included self-hosted needing sharding + backups without Enterprise licence
Atlas on K8s? — no. Atlas is managed; don't K8s it.

For new projects in 2026, MongoDB Controllers for Kubernetes Operator is the official path. Percona is a strong OSS alternative when you need sharding + PBM-style backups on Community.

Chapter 2 — Install the Controllers operator (Helm)

1
2
3
4
5
6
helm repo add mongodb https://mongodb.github.io/helm-charts
helm repo update
 
helm install mongodb-controllers mongodb/mongodb-kubernetes \
  --namespace mongodb --create-namespace

Creates the operator + CRDs (MongoDBCommunity, MongoDB, MongoDBUser, etc.) in the mongodb namespace.

Chapter 3 — Deploy a replica set

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# mongodb-replicaset.yaml
apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: shop-rs
  namespace: mongodb
spec:
  members: 3
  type: ReplicaSet
  version: "8.0.0"
  security:
    authentication: { modes: ["SCRAM"] }
  users:
    - name: shopuser
      db: admin
      passwordSecretRef: { name: shopuser-pw }
      roles:
        - { name: readWrite, db: shop }
      scramCredentialsSecretName: shopuser-scram
  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongod
              resources:
                limits:   { cpu: "2",    memory: "8Gi" }
                requests: { cpu: "500m", memory: "4Gi" }
      volumeClaimTemplates:
        - metadata: { name: data-volume }
          spec:
            accessModes: ["ReadWriteOnce"]
            resources: { requests: { storage: 50Gi } }
            storageClassName: ssd
 
1
2
3
kubectl apply -f mongodb-replicaset.yaml
kubectl get mdbc -n mongodb           # watch state

The operator provisions StatefulSet, PVCs, services, runs rs.initiate(), configures users.

A replica set YAML applied to the MongoDB Kubernetes operator, which creates a three-member StatefulSet, services and users

Chapter 4 — Production checklist

  • Storage: SSD class, ReadWriteOnce, ≥ 3× working-set size.
  • Node affinity: spread pods across nodes / zones (podAntiAffinity).
  • Resource requests + limits: match instance sizing.
  • PVC backup: Velero or CSI snapshots into S3.
  • Monitoring: deploy mongodb-prometheus-exporter sidecar; scrape into Prometheus → Grafana.
  • TLS: Operator creates cert-manager-backed certs; clients use them.
  • Network policies: only app namespace reaches mongod ports.
  • Backups: Percona Backup for MongoDB (PBM) sidecar, schedule + offsite S3.
  • Updates: roll one member at a time via Operator-managed updates.

Chapter 5 — When NOT to run Mongo on K8s

  • Atlas is available and you don't have a sovereignty / on-prem requirement → use Atlas. Saves enormous ops time.
  • Team has no K8s expertise → managed first, K8s later.
  • Small workloads (< 100 GB, < 1k QPS) → cheaper + simpler on plain VMs or managed.

K8s pays off when: you already run K8s for everything else; you have multiple stateful workloads to operate; on-prem or sovereign cloud is required; you need infra-as-code for the DB itself.

Part 2 — mongosync

Chapter 6 — What mongosync does

Mongosync replicates data continuously from a source cluster to a destination cluster, with minimal downtime cut-over. Works between any combination of self-hosted + Atlas + clouds + regions.

Use cases:

  • One-time migrations (on-prem → Atlas, AWS → GCP, cluster tier change).
  • Multi-region passive-standby — destination always current; failover updates DNS.
  • Pre-production environments — sync prod data nightly into staging (with PII scrubbing post-sync).
  • Reverse-sync for rollback.

Chapter 7 — Mongosync basics

1
2
3
4
5
mongosync \
  --cluster0 "mongodb+srv://srcuser:pw@src-cluster/" \
  --cluster1 "mongodb+srv://dstuser:pw@dst-cluster/" \
  --logPath /var/log/mongosync/

Then orchestrate via the REST API on localhost:27182:

1
2
3
4
5
6
7
8
9
10
# start initial sync
curl -X POST localhost:27182/api/v1/start \
  -d '{"source": "cluster0", "destination": "cluster1"}'
 
# track progress
curl localhost:27182/api/v1/progress
 
# commit (cut over)
curl -X POST localhost:27182/api/v1/commit

Phases:

  1. Initial sync — bulk copy of every doc.
  2. Steady state — continuous oplog tailing.
  3. Commit — drain remaining oplog, freeze writes briefly, declare destination authoritative.

Downtime for cut-over: seconds in normal cases.

mongosync copies one cluster into another in three phases, then the app's writes move after a brief freeze

Chapter 8 — Multi-region active-passive

1
2
3
4
5
6
Region A (primary writes)           Region B (passive standby)
       │                                       ▲
       │ writes                                │
       ▼                                       │
   Cluster A  ───── mongosync ──────────►  Cluster B

On region A outage:

  1. Stop the mongosync direction (or accept its catch-up lag).
  2. Flip your app's connection string / DNS to cluster B.
  3. Optionally start reverse mongosync (B → A) for when A recovers.

Active-active (writes in both regions) is not natively supported — last-writer-wins conflict resolution would be needed; Mongo doesn't have it. For active-active you typically shard by region (each region writes only to its own shard); mongosync isn't the right tool.

Chapter 9 — Sharded cluster sync

For sharded source + destination: run one mongosync per source shard to parallelise.

1
2
3
mongosync --cluster0 "mongodb://shard1/" --cluster1 "mongodb://destShard1/" ...
mongosync --cluster0 "mongodb://shard2/" --cluster1 "mongodb://destShard2/" ...

Coordinated commit ensures consistency on cut-over.

Chapter 10 — Mongosync vs other tools

Tool When
mongosync Mongo → Mongo; one-time or continuous
mongodump / mongorestore small / non-time-critical dumps; cross-version migrations
Debezium MongoDB connector Mongo → Kafka → anywhere (Post 24)
Atlas Live Migration one-time migration into Atlas
Atlas backup restore DR scenarios

For Mongo → Mongo, mongosync is the modern default.

Part 3 — Cost optimisation

Chapter 11 — Atlas tier sizing

Atlas pricing scales with tier (M0 free → M700+ enterprise). Cost levers:

  • Right-size the cluster by working set, not by RAM × N.
  • Reduce non-essential indexes (write amplification + RAM bloat).
  • Online Archive old data (Post 16) — 10× cheaper than hot tier.
  • Search nodes sized separately; right-size for index size + traffic.
  • Backup retention — long retention = more cost. Right-size to compliance need.
  • Data transfer — cross-region replication / clients in different regions = egress fees. Co-locate.

Chapter 12 — Index pruning

1
2
3
db.collection.aggregate([{ $indexStats: {} }])
// drop indexes with `ops: 0` over weeks

Hidden index pattern (Post 03) lets you test removal safely. Quarterly index review on every production collection. Easy 10-30 % storage + RAM win.

Chapter 13 — Query cost

Each slow query = wasted CPU + IOPS. The profiler + Atlas Performance Advisor (Post 04) surface them. Fix top-N slowest queries every sprint.

A query halved is two queries worth of capacity reclaimed. Index investments scale your fleet without scaling your tier.

Chapter 14 — Storage compression

  • WiredTiger default is snappy. Switching new collections to zstd (Post 15) compresses ~25 % better at similar CPU.
  • Old collections can be re-collected (offline) to apply new compression.

Chapter 15 — Connection cost

Each pool connection costs server-side resources. Right-size client pools by Little's Law (Post 08). Big over-pools waste Atlas tier capacity.

Chapter 16 — Hot vs cold tiers

For data that's queried rarely:

  • Atlas Online Archive → cheap S3-like storage; federated query.
  • Manual archive to S3 (Parquet, compressed) → cheapest, custom-query path.
  • For analytics, push old data to ClickHouse (Post 28).

The two ratios that matter: hot/cold size + hot/cold cost. If 80 % of data is rarely queried, tier it; you'll cut cluster cost in half.

Chapter 17 — Atlas cost-control tactics

Tactic Saving
Right-size tier up to 50 % if over-provisioned
Drop unused indexes 10-30 % RAM
Online Archive cold data 50 %+ on cold-heavy workloads
Switch to zstd 20-30 % storage
Co-locate clients + cluster data-transfer egress reduction
Annual commit / reserved pricing 20-40 % discount
Stop dev / staging clusters off-hours tier-hour reduction
Audit + cancel forgotten resources varies; can be huge

Chapter 18 — Self-hosted cost considerations

Cost = hardware (or cloud VMs) + storage + network + people-ops.

Compared to Atlas:

  • Self-hosted hardware is often cheaper per GB-RAM at large scale.
  • But operating cost (people, on-call, backup infra, monitoring) often exceeds the Atlas premium.
  • Most teams break even around ~50 nodes / multi-TB; below that, Atlas wins on TCO.

The right answer depends on your ops headcount + cloud commit + sovereignty needs.

Part 4 — Compliance

Chapter 19 — HIPAA, PCI-DSS, GDPR, SOC 2 baselines

These are the four most common compliance frameworks regulated workloads hit. Mongo + Atlas provides primitives; you assemble the controls.

Framework Concerns
HIPAA (US healthcare) Patient health info (PHI). Audit, encryption, access control, BAA with vendor.
PCI-DSS (cards) Cardholder data (PAN). Encryption, network isolation, key rotation, logging, scanning.
GDPR (EU) Personal data of EU residents. Right to be forgotten, data residency, breach notification (72 h).
SOC 2 (general trust) Security, availability, processing integrity, confidentiality, privacy. Audit-based.

Chapter 20 — Atlas + HIPAA

  • Atlas enterprise tier required + Business Associate Agreement (BAA) with MongoDB Inc.
  • Customer-managed KMS keys for encryption at rest.
  • Audit log enabled + shipped offsite.
  • TLS in transit (default).
  • VPC private endpoint; no public access.
  • MFA + SSO + RBAC for all users.
  • BAAs with every downstream subprocessor.

Document everything for the audit.

Chapter 21 — PCI-DSS

For storing PAN (primary account number):

  • CSFLE or Queryable Encryption (Post 13) so PAN is unreadable to ops staff.
  • KMS-managed keys with rotation policy + access logs.
  • Network isolation; no internet egress from the DB host.
  • Audit log capturing every PAN access + every privileged op.
  • Quarterly external scanning; annual penetration test.
  • Vendor PCI attestation (Atlas has SAQ-D Service Provider).

Better: don't store PAN at all. Use a tokenisation service (Stripe / Adyen / Spreedly); store tokens.

Chapter 22 — GDPR — right to be forgotten

Article 17 — data subjects can request deletion.

Patterns:

  • Hard delete via secondary key (email / customer_id). Find every collection referencing the subject; delete or anonymise. Mongo's lack of FK makes this app-side; document each collection's owner.
  • Soft delete via anonymisation — replace PII with placeholders; keep aggregate analytics integrity.
  • Backup considerations — backups also contain the subject's data. Most regulators accept "purged on backup rotation"; document the retention.
  • Audit — log every deletion request + resolution.
  • Data residency — Atlas regions match EU AWS / Azure / GCP regions to keep data in-EU.

Chapter 23 — SOC 2 controls — common requirements

  • Documented security policies (you write; auditor reviews).
  • Access reviews — quarterly audit of who has what role.
  • Change management — every prod change reviewed + approved.
  • Vendor management — Atlas + every downstream vendor reviewed.
  • Incident response plan — written + practised.
  • Monitoring + alerts — proven via logs.
  • Backup + restore — tested (Post 14).

The audit checks evidence over a 6 or 12 month observation period. Tooling (Vanta, Drata, Secureframe) automates most of the evidence collection.

Chapter 24 — Audit logging discipline

Every privileged operation + every data access on sensitive collections should be auditable:

  • Atlas audit log → SIEM (Splunk, Datadog, ELK).
  • Self-hosted: Enterprise audit log feature, with filters for noise reduction.
  • App-level audit: every PII-touching endpoint logs (user, action, target_id, at) into an audit_log collection with TTL of regulator-required years.

Chapter 25 — Common pitfalls (compliance)

Pitfall Cause Fix
PAN in plaintext "we'll encrypt later" tokenise via payment provider; never store
EU data in US region accidental cluster region always pin region for GDPR-relevant data
Audit log not preserved retention too short retention by regulator (often 7 years for HIPAA)
Backups not encrypted self-hosted pipeline missed encrypt every backup at rest
MFA only on humans, not service accounts service accounts hijacked use IAM auth where possible; rotate other secrets
Deletion request not honoured backups still hold the data document backup-rotation purge; honour as best-effort
Privileged role too broad default dbOwner instead of custom least-privilege custom roles

Course complete

You've covered MongoDB from the document model through CRUD, indexes, aggregation, schema design, pool + concurrency, transactions, replication, sharding, change streams, security, backup, performance, Atlas (Search + Vector + Triggers + Stream Processing), drivers, modelling case studies, Mongoose, Beanie, the outbox pattern, CQRS + Event Sourcing, production RAG, SQL→Mongo migration, Kafka + Debezium CDC, testing, OpenTelemetry, geospatial, time-series at extreme scale, Kubernetes, mongosync, cost, and compliance.

That's the working knowledge of a senior MongoDB engineer + the architectural awareness of a platform engineer. Where you go from here:

  • Read MongoDB Inc. release notes per major version — the engine evolves fast.
  • Build something real that exercises 5+ of these areas end-to-end.
  • Contribute to OSS — drivers, operators, ODMs all welcome patches.
  • Pair with a database that complements Mongo for your edge cases (ClickHouse for analytics, Redis for hot cache).

The series will get future extensions (single-post deep dives on subtopics, case studies from real production migrations, performance benchmarks). The base + advanced you have today is enough to ship serious systems.

Cheat-sheet (omnibus)

Area Key
K8s operator MongoDB Controllers (new) > Community / Enterprise (older) > Percona (OSS sharding+backup)
K8s sizing SSD storage class; PVC ≥ 3× working-set; podAntiAffinity across zones
K8s vs Atlas Atlas almost always wins on TCO unless sovereign / on-prem
mongosync source → destination; commit phase has seconds of downtime
Multi-region active-passive mongosync + DNS flip on outage
Active-active not native; use region-sharded writes
Atlas cost levers right-size tier; drop unused indexes; archive; zstd; co-locate clients
Self-hosted cost wins at large scale + headcount; loses on small/medium
HIPAA BAA + CMK + audit log + private endpoint + MFA
PCI CSFLE / QE + KMS + tokenise where possible
GDPR right to be forgotten; data residency; document backups
SOC 2 document + audit; tools like Vanta automate evidence
Compliance baseline least-privilege RBAC + TLS + audit log + tested restore

References

Note: this post is in progress. Planned additions: end-to-end K8s operator walkthrough with TLS + backups; multi-region mongosync drill; Atlas cost case studies; PCI-DSS scope-reduction patterns via tokenisation.