Migrating from Atlas Data API and Custom HTTPS Endpoints (Previously Realm) – What Are Your Options

MongoDB's decision to deprecate the Atlas Data API and Custom HTTPS Endpoints (formerly MongoDB Realm) impacts thousands of applications that relied on HTTP-based access to Atlas clusters. These services provided convenient REST endpoints for serverless architectures, mobile applications, and microservices that needed direct database access without managing dedicated server infrastructure.

The deprecation reflects the cloud-native ecosystem's evolution toward purpose-built serverless functions, managed API gateways, and GraphQL layers that offer better security, performance, and scalability than generic HTTP-to-database proxies. Teams must now migrate to modern alternatives — but the migration path depends on application architecture, performance requirements, and team expertise. This guide provides a structured migration framework covering all viable alternatives.

Before choosing a migration path, audit every dependency on the deprecated services:

• Atlas Data API Consumers: Identify all applications making HTTP requests to Atlas Data API endpoints — serverless functions, mobile apps, IoT devices, third-party integrations, and internal tools. Document request patterns, authentication methods, and data volumes.
• Custom HTTPS Endpoints: Map all custom server-side logic deployed as Realm/Atlas HTTPS endpoints — these combined business logic with data access, requiring both API and compute migration.
• Authentication Dependencies: Atlas Data API used API keys and JWT-based authentication — replacement services need equivalent or stronger auth mechanisms. Document which clients use which auth methods.
• Trigger and Scheduled Functions: Atlas App Services triggers (database triggers, scheduled triggers, authentication triggers) that co-existed with HTTPS endpoints need separate migration paths to Atlas Functions or cloud-native alternatives.
• Data Access Patterns: Analyse query patterns — simple CRUD operations migrate easily, but complex aggregation pipelines, change streams, and transactions require careful translation to new service layers.

Atlas Functions provide the closest migration path — serverless JavaScript/TypeScript functions running within the Atlas ecosystem:

• Direct Atlas Integration: Functions access MongoDB collections through the built-in context.services API — no connection string management, connection pooling, or driver configuration. Queries execute within Atlas's network with minimal latency.
• HTTP Endpoint Replacement: Expose functions as HTTPS endpoints with configurable authentication (API key, JWT, anonymous) — direct 1:1 replacement for deprecated Custom HTTPS Endpoints with the same URL pattern capabilities.
• Event-Driven Triggers: Database triggers fire functions on insert/update/delete operations — replace change stream-based logic with declarative trigger configuration. Scheduled triggers replace cron-based Atlas Data API polling patterns.
• Migration Steps: (1) Extract business logic from existing HTTPS endpoints, (2) create Atlas Functions with equivalent logic, (3) configure HTTPS endpoint routing, (4) update client applications to new endpoint URLs, (5) validate with parallel testing before cutover.
• Limitations: 300-second execution timeout, 350MB memory limit, and limited runtime environment (Node.js subset). Complex applications with heavy compute, large file processing, or custom npm dependencies may need alternative solutions.

For applications needing full serverless flexibility, AWS Lambda provides the most capable alternative:

• Architecture: API Gateway handles HTTP routing, authentication, and rate limiting — Lambda functions execute business logic and connect to MongoDB Atlas using the official Node.js/Python driver. Use VPC peering or PrivateLink for secure Atlas connectivity.
• Connection Management: MongoDB connections must persist across Lambda invocations — initialise the MongoClient outside the handler function and reuse connections. Set maxPoolSize: 1 for Lambda to prevent connection exhaustion.
• Cold Start Mitigation: Use provisioned concurrency for latency-sensitive endpoints, ARM64 (Graviton) for 20% cost reduction, and Lambda layers for shared dependencies (MongoDB driver, utility libraries).
• API Gateway Integration: Configure REST API or HTTP API (lower cost) with Lambda proxy integration — API Gateway handles authentication (Cognito, API keys, custom authorisers), CORS, throttling, and request validation.
• Cost Model: Pay-per-request pricing (Lambda: $0.20/million invocations + compute time, API Gateway: $1.00-3.50/million requests) — typically 40-60% cheaper than always-on server infrastructure for variable traffic patterns.

For applications that consumed Atlas Data API for flexible data queries, GraphQL provides a superior replacement:

• Hasura: Instant GraphQL API over MongoDB with real-time subscriptions — auto-generates queries, mutations, and subscriptions from collection schemas. Supports role-based access control (RBAC), webhook authentication, and remote schemas for composing multiple data sources.
• Apollo GraphQL: Build custom GraphQL servers with Apollo Server — define schemas, resolvers, and data sources. Apollo Federation enables microservices composition. Apollo Client handles caching, pagination, and optimistic updates on the frontend.
• MongoDB Atlas GraphQL: Atlas provides native GraphQL endpoint generation — define schemas in Atlas App Services, configure access rules per collection, and expose a managed GraphQL endpoint. Simpler than Hasura but less feature-rich.
• Migration Benefits: GraphQL eliminates over-fetching and under-fetching problems inherent in REST/Data API — clients request exactly the fields they need, reducing bandwidth and improving mobile performance.
• Schema Stitching: Combine MongoDB data with other sources (PostgreSQL, REST APIs, microservices) in a single GraphQL gateway — provide unified data access without client-side data orchestration.

For applications that can manage server-side infrastructure, migrating to direct MongoDB driver access provides maximum control:

• Node.js/Express Backend: Replace Data API HTTP calls with MongoDB Node.js driver queries — MongoClient.connect() with connection pooling, retry logic, and read/write concern configuration. Express.js or Fastify provides the HTTP layer.
• Mongoose ODM: For applications needing schema validation and middleware — Mongoose provides schema definitions, pre/post hooks, virtuals, and population for MongoDB. Ideal for structured applications that previously relied on Data API's implicit schema handling.
• Connection Pooling: Configure optimal pool sizes based on workload — maxPoolSize: 10 for typical web servers, minPoolSize: 5 to avoid cold connection latency. Monitor pool metrics with MongoDB driver events.
• Replica Set Awareness: Configure read preferences (secondaryPreferred for read-heavy workloads), write concerns (w: "majority" for durability), and retry writes for automatic failover handling.
• Containerised Deployment: Deploy Node.js backend in Docker containers on AWS ECS, Azure Container Apps, or Google Cloud Run — auto-scaling, health checks, and managed SSL without server administration.

Migration validation requires comprehensive testing at every layer:

• API Compatibility Testing: Record all existing Data API request/response pairs — replay against the new implementation and validate response bodies, status codes, headers, and latency. Use tools like Postman collections or k6 for automated API testing.
• Data Consistency Verification: Run parallel queries against both old and new implementations during the transition period — compare results programmatically to catch query translation errors, especially in aggregation pipelines and projection fields.
• Load Testing: Simulate production traffic patterns against the new backend — validate that connection pooling, cold starts (Lambda), and auto-scaling handle peak loads. Use k6 or Artillery with realistic concurrency levels.
• Authentication Testing: Verify all authentication flows work with the new service — API key validation, JWT token verification, OAuth flows, and anonymous access. Test token expiration, refresh, and revocation scenarios.
• Rollback Procedure: Maintain the ability to route traffic back to Atlas Data API during the migration window — use DNS-based routing, API gateway traffic splitting, or feature flags to control cutover percentage.

Successful production migration requires phased execution with safety nets:

• Canary Deployment: Route 5-10% of traffic to the new implementation — monitor error rates, latency p99, and data consistency before increasing traffic percentage. Use API gateway weighted routing or feature flags for traffic control.
• Blue-Green Switchover: Run both old and new implementations simultaneously — cut over DNS/routing when canary validation passes. Maintain the old implementation for 2-4 weeks as a rollback path.
• Client SDK Updates: Update mobile and frontend SDKs to point to new endpoints — use configuration-based endpoint URLs (environment variables, remote config) rather than hardcoded URLs to enable future migrations.
• Monitoring Dashboard: Create unified monitoring for the new stack — track request rates, error rates, latency distributions, MongoDB connection pool utilisation, and Lambda/function cold start frequency. Set alerts for degradation.
• Documentation and Runbooks: Document the new architecture, deployment procedures, troubleshooting guides, and incident response procedures — ensure the operations team is trained before deprecation deadline.

MDS provides end-to-end Atlas migration services — from impact assessment and architecture design through implementation, testing, and production cutover, ensuring zero-downtime transition from deprecated Atlas Data API to modern, scalable alternatives.