Back to all use cases

AssessmentSoftware / Digital Platforms

Finding the pipelines and transactions that decide the move before choosing the target

SaaS Platform Team

A typical engagement for a team that wants to consolidate on PostgreSQL: documents, aggregation pipelines, transactions and change streams assessed against a JSONB design, with a stay, proxy or leave recommendation.

Overview

A typical engagement starts with a SaaS platform team that runs MongoDB next to PostgreSQL and wants to retire one of them. The reasons vary: licence terms, a hosting bill, or the cost of running two engines. The open question is how much of the MongoDB usage PostgreSQL can absorb.

Challenge

Simple collections move easily. Aggregation pipelines with lookups, multi-document transactions, change streams and BSON types need a decision each, and proxy layers that speak the MongoDB protocol document features they do not support. A compatibility percentage cannot answer whether this application will run, so the answer has to come from the application's own usage.

Environment

A MongoDB replica set or sharded cluster behind several services, a PostgreSQL estate already in production, and application code that uses the MongoDB drivers, aggregation pipelines, sessions and, in places, change streams.

Approach

AceMQ engineers search the code for pipeline stages, transactions and change streams, then profile collections by size, document shape, index use and write rate. Each finding is mapped to a JSONB design, to a MongoDB-compatible proxy on PostgreSQL, or to a reason to stay. A sample collection is loaded into PostgreSQL to test the design and the data-type rules.

Solution

  1. Code and workload inventory of pipeline stages, transactions, change streams and BSON types, with traffic attached to each
  2. Collection profile covering document size, nesting, indexes and write rate, and sharding needs
  3. JSONB and relational design for the main collections, with the fields promoted to columns
  4. Check of the MongoDB-compatible proxy options against the documented unsupported features
  5. Replacement design for change-stream consumers, such as logical decoding or a CDC tool
  6. Written stay, proxy or leave recommendation with a rehearsed-cutover plan and a rollback point

Outcome

The engagement delivers the inventory, a JSONB design for the main collections, a feature-by-feature verdict on the proxy options, and a written recommendation with a phased cutover plan. If a collection or service is better left on MongoDB, the report says so and why.

Technologies

MongoDBPostgreSQLDebezium
  • Assessment

    MongoDB Deployment Health Assessment

    Public Sector AgencyGovernment

    Structured review of schema design, index efficiency, replica set topology, and backup recoverability ahead of a major workload increase.

    MongoDBLinuxPrometheusKubernetes
    Read case study: MongoDB Deployment Health Assessment
  • Consulting

    MongoDB Sharding Strategy and Shard Key Redesign

    Logistics and Freight Technology ProviderCross-Industry

    Redesigning a monotonically increasing shard key that concentrated all inserts on one shard and produced jumbo chunks that would not split.

    MongoDBKubernetesKafkaTerraform
    Read case study: MongoDB Sharding Strategy and Shard Key Redesign
  • Assessment

    Db2 DBA Cover and a PostgreSQL Feasibility Assessment

    Regional InsurerFinancial Services

    A typical engagement: AceMQ provides remote and on-call DBA cover for an insurer's IBM Db2 LUW estate and assesses which databases could move to PostgreSQL and which should stay.

    IBM Db2PostgreSQLDebezium
    Read case study: Db2 DBA Cover and a PostgreSQL Feasibility Assessment
  • Support

    Apache Airflow DAG Parse Time Support

    Digital Retail PlatformSoftware

    Fixing scheduler delay caused by DAG files that make network or database calls at parse time, blocking every DAG in the deployment.

    Apache AirflowKubernetesPostgreSQL
    Read case study: Apache Airflow DAG Parse Time Support
  • Assessment

    Managing Spring Framework CVE Risk at Enterprise Scale

    Enterprise Software OrganizationsSoftware

    AceMQ helps enterprise software organizations quantify and manage the CVE risk exposure created by running community Spring Framework without a commercial support agreement, transitioning them to Broadcom commercial support.

    Spring Framework
    Read case study: Managing Spring Framework CVE Risk at Enterprise Scale

Related Reading

Ready for a MongoDB Health Check?

AceMQ's senior MongoDB engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.