For MongoDB

MongoDB on Edge,
Atlas-class without the price

Self-hosted MongoDB Community on dedicated NVMe, replica sets across Edge VMs, archives to S3-compatible storage. Same Mongo you know, on infrastructure you actually own.

Start your trial Have us run it

# Provision a 3-node replica set

$ edge compute create --plan db-medium \

--count 3 --script ./bootstrap-mongo.sh

# mongod.conf — replica set + bind

net:

bindIp: 10.0.0.0/8

replication:

replSetName: rs0

# Initialise from one node

$ mongosh --eval "rs.initiate(...)"

# Nightly archive → Edge Storage

$ mongodump --archive --gzip | \

aws s3 cp - s3://mongo-backups/$(date +%F).gz \

--endpoint storage.edge.run

Why Mongo teams pick Edge

All the document-DB ergonomics, none of the Atlas markup.

NVMe for hot working sets

WiredTiger thrives on real disk. Dedicated NVMe on every Edge VM keeps the working set hot and the p99 sane.

Replica sets across VMs

Three-node replica sets across separate Edge VMs over private networking. Automatic failover, no Atlas premium for the privilege.

mongodump → S3

Schedule `mongodump --archive --gzip` to Edge Storage, restore with `mongorestore`. Cheap, durable, no per-snapshot fees.

Atlas Search alternatives

Run native text indexes for simple cases, or stand up MeiliSearch / Elasticsearch on a separate VM if you need full-text. Your call, no platform lock-in.

Community or Enterprise

MongoDB Community Server runs cleanly. If you have an Enterprise licence (LDAP, encryption-at-rest, audit), that runs too — same install pattern.

No per-IOPS Atlas surprise

Atlas M30 + 500GB storage + IOPS provisioning is ~$700/month. The same workload on a 3-node Edge replica set is a fraction of that — same Mongo, no markup.

Reference architecture

How Mongo maps to Edge

Three-node replica set, NVMe per node, archives to a bucket. Standard Mongo ops, modern infrastructure.

Compute

Three Mongo VMs forming a replica set, NVMe data directory on each

Storage

mongodump archives + oplog snapshots to a bucket for PITR

DNS

Anycast DNS for `db.example.com` (round-robin or primary-aware)

Compute (search)

Optional MeiliSearch / Elasticsearch VM if you need real text search

# Connect from your app

MONGO_URI="mongodb://mongo-1:27017,mongo-2:27017,mongo-3:27017/app?replicaSet=rs0"

# Standard driver code

const client = new MongoClient(process.env.MONGO_URI)

const db = client.db('app')

const users = db.collection('users')

# Sub-ms over private networking

{ acknowledged: true, insertedId: ObjectId(...) }

Common questions

How does this compare to Atlas?

Cheaper (no per-IOPS billing, no per-snapshot fees, no inter-AZ data transfer), and you keep root. Trade-off: you handle backups, upgrades and replica-set provisioning — or our Expert Services team can.

Can I use the official drivers unchanged?

Yes — point your driver at the replica-set hostnames and you're away. Same Mongo wire protocol, same connection strings, same client libraries.

What about backups and PITR?

Combine `mongodump` to Edge Storage on a schedule with oplog tailing for point-in-time recovery. There are several open-source tools (e.g. Percona Backup for MongoDB) that automate this.

Sharding?

Yes — config servers, mongos routers and shards are all just more VMs. Spread them across regions over private networking. We have customers running multi-TB sharded clusters this way.

By Stack