One App, Three Databases: Why Motion uses MongoDB, Elasticsearch, & PostgreSQL — & keeping them all

When AI tooling defaults to PostgreSQL and every new ORM ships a Postgres driver first, it is tempting to ask: should we just consolidate everything into Postgres? This talk answers that question honestly — with real architecture decisions, real migration cost analysis, and a frank look at why polyglot persistence is often the right call, not technical debt to be eliminated.

Motion is a creative advertising analytics platform. Marketers use it to understand ad performance across Meta, TikTok, YouTube, and LinkedIn and to research and analyze creative content at scale. We run three purpose-built databases in production.

MongoDB handles the operational core. Ad platform data is the problem case for rigid schemas: Meta, TikTok, YouTube, and LinkedIn each model ad units, insights, and breakdowns differently. The document model absorbs that schema variance without migrations every time a platform ships a new field shape. Aggregation pipelines and change streams power the core sync and analytics architecture.

Elasticsearch handles what MongoDB cannot serve economically at scale: faceted aggregations across hundreds of millions of ad insight records, full-text creative search with analyzers and synonyms, and fast metric rollups for analytics dashboards. We sync operational data into Elasticsearch — tools like Monstache make this tractable — to get the best of both: MongoDB’s operational flexibility and Elasticsearch’s aggregation and search performance.

PostgreSQL anchors our AI workflow builder, a separate product built from scratch. Workflows, branches, nodes, edges, and run history form a graph structure that is inherently relational. Strict foreign keys, auditable run history, and join-heavy queries made Postgres the right tool for this workload. This is not a pgvector story — our memory and retrieval layer uses a managed external service, and the Postgres decision was purely about workflow state modeling.

We will share what it would actually cost to migrate core MongoDB workloads to Postgres: schema redesign for variable ad platform shapes, query rewrites, operational tooling replacement, and the subtler cost of losing aggregation pipeline patterns that power the core product.

The lesson: polyglot persistence is not a liability. It is purposeful specialization — and consolidation has a real price that rarely pencils out.

Key Takeaways:

• The specific workload characteristics that make MongoDB, Elasticsearch, and PostgreSQL each the right choice

• Why multi-platform ad data is a strong case for the document model over relational tables

• The MongoDB → Elasticsearch sync pattern for teams needing analytics performance without migrating operational data

• Real cost categories for migrating away from MongoDB that teams routinely underestimate

• How to justify a multi-database architecture to leadership — and when consolidation actually does make sense

Target Audience: Architects, engineering leads, and senior engineers navigating database strategy decisions — especially teams feeling pressure to consolidate or modernize onto a single database.