Features and architecture
FPT MongoDB Enterprise runs on FPT Cloud's cloud-native infrastructure, with operational and protection components built in rather than added afterwards. This page covers what the service can do, and the one architectural decision you cannot change later.
Capability summary
Capabilities fall into eight areas. Some are always on; others need enabling before they protect or report on anything. The last column is the one to read if you are planning a production deployment.
| Area | What you get | On by default? |
|---|---|---|
| Database management & operations | Central console to provision, configure, and operate clusters. Lifecycle automation covers provisioning, resource scaling, parameter configuration, and service management. | Yes |
| High Availability & scalability | Standalone, Replica Set, and Sharded Cluster architectures. Automatic failover on Replica Set and within each shard. Horizontal scale-out across shards. | Architecture is chosen at provisioning |
| Backup & recovery | Scheduled automated backups and point-in-time recovery. | Backup and PITR are enabled at creation, but no data is protected until a backup job exists and has run |
| Monitoring & alerting | Real-time metrics (CPU, memory, IOPS, connections) through FPT Monitoring, with Grafana dashboards and log exploration. | No — contact FPT Support to enable |
| Security & compliance | Encryption at rest and in transit, RBAC, VPC integration, IP-based access control. | Yes |
| Performance optimization | Engine configuration, indexing strategy, query optimization. | Yours to apply |
| Logging & auditing | Centralized logging and audit trails for troubleshooting and compliance. | Yes |
| Managed service & support | 24/7 operations by FPT Cloud, with incident response against an SLA. | Yes |
The two that need action
Most of the list above works the moment your cluster is running. Two do not, and each has caught people out:
- Backups. The backup service is enabled when you create a cluster, but that only means the service is available. Until a backup job is configured and has completed a run, there is no restore point. See Backup & Restore overview.
- Monitoring. Not self-service. The Monitor tab prompts you to contact FPT Support, who enable collection for the cluster. See Monitor & alert.
Choosing an architecture
This is the decision that matters most, because it is fixed at provisioning time. It determines whether your cluster survives losing a node, and whether it can grow past the capacity of a single machine.
| Standalone | Replica Set | Sharded Cluster | |
|---|---|---|---|
| Topology | One database instance, no replication | One Primary plus multiple Secondary nodes | Several shards, each its own 3-node replica set, behind mongos routers and a 3-node config server |
| Automatic failover | No | Yes | Yes, within each shard |
| Data replication | No | Yes | Yes, within each shard |
| How you add capacity | Larger node only | Larger nodes, or more nodes | Larger nodes, more mongos routers, or more shards |
| Reduced disruption during version upgrade | No | Yes | Yes |
| Deployment speed | Fastest | Slower | Slowest |
| Smallest deployment | 1 node | 3 nodes | 11 nodes |
| Recommended for | Development, testing, staging, small workloads | Production and anything needing fault tolerance | Data volume or write throughput one replica set can no longer carry |
Standalone is quick to deploy, cheaper, and simpler to manage. The trade-off is total: there is no failover, and if the node becomes unavailable the service stops.
Replica Set replicates data across nodes and promotes a Secondary automatically when the Primary fails, which keeps the service running through a node failure. Every node still holds the full dataset, so the largest node you can buy is the ceiling.
Sharded Cluster removes that ceiling. The data is partitioned across shards by a shard key, and each shard stores only its own share, so capacity and write throughput grow with the number of shards rather than with node size. You pay for it in node count and in operational complexity — the smallest cluster the console will build is 11 nodes, and query performance now depends on choosing a shard key that spreads work evenly.
What a Sharded Cluster is made of
Three distinct node roles, each sized separately when you provision:
| Role | What it does | Node count |
|---|---|---|
| Mongos | Query router. Clients connect here, not to the shards. It reads the cluster metadata and forwards each operation to the shards that hold the relevant data. Stateless, so it holds no data of its own. | 2 to 32, your choice |
| Shard | Holds one partition of the data. Each shard is deployed as a 3-node replica set, so a shard survives losing a node on its own. | 2 to 32 shards, your choice — so 6 to 96 data nodes |
| ConfigServer | Stores the cluster metadata: which chunk of the shard key range lives on which shard. Deployed as a replica set. | Fixed at 3 |
A 2-shard cluster is therefore 2 mongos + (2 × 3) shard nodes + 3 config servers = 11 nodes.
The shard count is not locked in at creation — you can raise it later from the cluster's Overview tab, along with the number of mongos routers. The config server stays at 3 either way. See Scale out a database cluster.
Adding a shard is still an operation to plan, not a setting to flip: MongoDB redistributes data across the new shard set, and performance dips while that runs. Sizing roughly for the data you expect saves you a rebalance later.
The architecture type is set when the cluster is created and cannot be changed afterwards. Moving between Standalone, Replica Set, and Sharded Cluster means provisioning a new cluster and migrating the data. Choose Replica Set if there is any chance the workload becomes production, and Sharded Cluster only once you know a single replica set will not hold the data.
Platform components
Around the database itself, the service integrates centralized components that cover the cluster's whole lifecycle:
- Monitoring — metrics and logs, surfaced through FPT Monitoring and Grafana
- Logging — centralized collection for troubleshooting and audit
- Backup and restore — scheduled backups plus point-in-time recovery
- Automated alerts — email and Telegram delivery on backup, resource, scaling, and maintenance events
Resource scaling runs online: vCPU, RAM, and storage can be adjusted without taking the cluster down, within the quota available to your VPC.
Isolation and security
The architecture applies multi-layer isolation, combined with:
- Network isolation through VPC placement, so the cluster sits inside your own network boundary
- Encryption of data at rest and in transit
- Access control through IAM roles and Security Groups
Together these keep data protected both where it is stored and while it moves.
Next steps
- Database engine versions for the supported version catalog
- Connect to database with Floating IP for endpoints, access models, and Security Groups
- Create your first database once you have chosen an architecture