Database guides
Amazon DocumentDB
AWS-managed documents with MongoDB API compatibility. AddisDB connects with its Mongo driver — the same editor, the same grid.
Amazon DocumentDB implements the MongoDB API on top of AWS’s own storage engine. AddisDB connects with its MongoDB driver, so collections appear in the sidebar like tables, commands run from the editor, and documents land in the grid with the raw JSON one tab away.
Who it is for
DocumentDB suits teams who want the MongoDB programming model with AWS operating it — backups, patching and failover included, inside your VPC and your IAM story.
Underneath, it is not MongoDB at all: it reimplements the API over the same distributed storage layer Aurora uses, with a writer and up to fifteen readers sharing one volume. That is why failover is fast and why the feature set tracks a specific API level rather than MongoDB releases.
If you need the newest MongoDB features the moment they ship, MongoDB Atlas tracks them and DocumentDB does not.
Set up the cluster
- Create a DocumentDB cluster and note the cluster endpoint.
- DocumentDB is VPC-only — there is no public endpoint. Plan to reach it from an EC2 bastion, a VPN, or an SSH tunnel.
- Download the Amazon RDS CA bundle. TLS is on by default and the cluster presents an Amazon-issued certificate.
- Note the master username and password you set at creation.
- Use the cluster endpoint rather than an instance endpoint, so a failover does not leave your connection pointed at a former primary.
Connect from AddisDB
- New Connection → Amazon DocumentDB. Port prefills to 27017 and database to admin.
- Because the cluster is VPC-only, use AddisDB’s SSH tunnel through your bastion rather than forwarding a port by hand.
- Enter the master username and password.
- Point the CA certificate field at the RDS CA bundle you downloaded, and leave certificate verification on.
- Test, then Save.
Where the compatibility stops
The gaps are specific and worth knowing before you port a query: no $lookup with a pipeline in older API levels, no change streams on all collections, limited support for certain aggregation stages, and no server-side JavaScript at all. When a stage is unsupported the cluster rejects it, so the error you see is AWS’s wording rather than a client-side check.
// The editor is the same as MongoDB’s — a bare name, or a command document
orders
{ "find": "orders", "filter": { "status": "shipped" }, "limit": 50 }
// Check what this cluster actually implements before porting a pipeline
{ "buildInfo": 1 }
What AddisDB gives you
- Collections browsable in the sidebar, with inferred columns from a sampled document.
- Any command document run from the editor, results flattened into the grid, raw JSON one tab away.
- Read-only enforcement: on a read-only connection, a write command — or an aggregate with $out or $merge — is refused before it is sent.
- SSH and AWS SSM tunnels, the Chart view, ⌘K search and AI chat grounded in your collections.