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 | Single Node and Replica Set architectures. Automatic failover on Replica Set; vertical scaling of vCPU, RAM, and storage. | 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 three that need action
Most of the list above works the moment your cluster is running. Three 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 Monitoring.
- Auto Vertical Scaling. Requires the Notification service to be configured first, with at least one email or Telegram recipient. The system refuses to enable scaling without somewhere to send the alerts. See Auto Vertical Scaling.
Choosing an architecture
This is the decision that matters most, because it is fixed at provisioning time and determines whether your cluster survives losing a node.
| Single Node | Replica Set | |
|---|---|---|
| Topology | One database instance, no replication | One Primary plus multiple Secondary nodes |
| Automatic failover | No | Yes |
| Data replication | No | Yes |
| Reduced disruption during version upgrade | No | Yes |
| Deployment speed | Faster | Slower |
| Cost | Lower | Higher |
| Recommended for | Development, testing, staging, small workloads | Production and anything needing fault tolerance |
Single Node 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.
The architecture type is set when the cluster is created and cannot be changed afterwards. Moving from Single Node to Replica Set means provisioning a new cluster and migrating the data. Choose Replica Set if there is any chance the workload becomes production.
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