Scaling Data Modeling for Enterprise

01 — Context

The problem

Ellie.ai is a collaborative data modeling tool used by data engineers, architects, and analysts to design and document database schemas. As the product started attracting enterprise interest, the existing free-form canvas — built for solo users — began to break down under team conditions: no access control, no review process, no way to manage change across large, complex models.

01 Any team member could edit any part of the model at any time — there was no concept of ownership, review, or approval.
02 Enterprises needed audit trails and governance workflows before they could sign contracts. We had neither.
03 Large schemas became impossible to navigate — hundreds of tables with no grouping, filtering, or contextual structure.
04 Data sources lived outside the tool, so models were always partially stale. There was no way to sync or validate against real data.

Workflows stalled

Teams couldn't scale — assets duplicated, metadata drifted out of control

High onboarding friction

New team members had no clear path into the existing structure

Enterprise deals at risk

Procurement required governance proof we couldn't provide

02 — Research

What we thought vs. what we learned

Initially, we assumed the issue was mainly about missing features. To validate this, I ran multiple research streams in parallel — and what we found changed the direction entirely.

Moderated interviews with enterprise clients Workflow deep dives Continuous feedback sessions Usability testing Market & competitor analysis

The problem wasn't just missing functionality — it was the lack of a system. Users weren't struggling with individual actions; they were struggling to maintain control over their entire data ecosystem. After multiple interviews with data engineers, team leads, and CTOs at mid-to-large companies, that shift in framing became impossible to ignore.

We assumed

Enterprises wanted a more powerful canvas with richer diagramming tools

Teams would self-organize ownership of schemas naturally

A simple permission system (view/edit) would cover most governance needs

Integrations with BI tools were the top priority feature request

We learned

They needed governance workflows more than visual features — approval chains, not prettier shapes

Ownership broke down at scale; they needed explicit assignment and review requests

Enterprise needed change history, rollback, and audit logs — the "who changed what" was critical

Source data integrations to keep models fresh were the real blocker to adoption

Key insights

01

Structure is a feature, not a constraint

Enterprise users actively wanted boundaries. Unlimited freedom created anxiety — they couldn't trust a model that anyone could change at any time.

02

The bottleneck was trust, not tooling

Enterprises weren't blocked by missing features — they were blocked by not being able to show legal and compliance that the system was auditable.

03

Staleness kills adoption

If a model doesn't reflect the real database, no one looks at it. Every team we spoke to had an "official" data model that was quietly ignored.

04

Collaboration ≠ simultaneous editing

Teams didn't want Google Docs for databases. They wanted async review workflows — propose, review, approve, merge. Like GitHub for schemas.

03 — Approach

UX Solution

We reframed the problem from "improve the canvas" to "make enterprise data teams feel safe." That meant introducing structural layers that didn't exist before.

How might we

Enable large teams to manage, scale, and trust their data workflows — without losing flexibility?

Exploration

Option A

Minimal improvements

Quick wins — patch the most obvious gaps without rethinking the underlying system.

+ Fast to ship − Doesn't scale

Option B

Fully structured system

Rebuild everything around hierarchy, versioning, and governance from scratch.

+ Scalable long-term − Too complex to ship fast

Chosen

Option C

Hybrid approach

Introduce structure progressively — governance where it matters most, flexibility preserved elsewhere.

+ Balanced − Requires careful UX decisions

The approach

We redesigned the system around three pillars: Structure (folders, hierarchy, grouping), Reusability (shared components and templates), and Governance (approval and merge workflows). These translated into four concrete UX surfaces.

1

Domain-based organisation

Introduced a domain/subdomain layer above tables — giving teams a way to group, own, and navigate large schemas by business area rather than raw alphabetical lists. Ownership at the domain level cascades down.

2

Proposal & approval workflow

Any structural change (new table, column type change, relationship added) can be proposed as a diff and sent for review. Domain owners approve or reject with comments. Full change history is retained.

3

Role-based access control

Beyond view/edit — Viewer, Contributor, Domain Owner, and Admin roles, each with clearly defined write scopes. Enterprises can onboard whole teams without giving everyone the keys.

4

Workflow-based data integration

Connect directly to Postgres, Snowflake, BigQuery — and sync the live schema into Ellie. Divergences between the model and the real database surface automatically, so the model stays trustworthy.

04 — Decisions

Trade-offs

Direct editing vs. branching — why support both?

The canvas already supported real-time collaborative editing — multiple people working simultaneously, like Figma. That stays. Branching was added on top for situations that require governance: proposed changes that need review, approval, and an audit trail before merging. The two modes aren't competing — direct editing is for exploration and small teams, branching is for changes that affect shared, production-grade models.

The approval workflow was too complex to ship all at once

Early designs of the full approval system were overwhelming — too many states, too many edge cases, too much to build and test at once. We made a deliberate call to split it into phases: first ship propose + reject, then add comment threads, then merge history. Each release was usable on its own, and we improved based on real feedback rather than building everything in the dark.

Did the enterprise push leave smaller customers behind?

That was a real risk. Enterprise governance features are overkill for a 3-person startup — they add friction where none is needed. So alongside the enterprise tier we launched a lighter version: simpler pricing, no branching required, collaboration without approval gates. The goal was to keep the product accessible at every stage of a team's growth, not just at scale.

05 — Features delivered

Key features delivered

Structure & Navigation

Domain-based schema organisation

Large schemas are grouped into business domains — each with an owner, description, and contained table set. Navigation shifts from scrolling through hundreds of tables to browsing meaningful areas of the business.

Human Control & Approval

Review & approval workflow

Contributors propose schema changes as diffs. Domain owners review, comment, and approve or reject. Every decision is logged — giving enterprises the audit trail compliance teams need before signing contracts.

Workflow-Based Data Integration

Live schema sync with divergence detection

With 160+ source integrations, teams can connect directly to Postgres, Snowflake, BigQuery, and more. Ellie pulls the live schema and highlights any drift between the documented model and the real database — so the model stays trustworthy, not aspirational. Divergences surface automatically, inline, without manual audits.

Canvas

Redesigned modeling canvas

A fully updated canvas experience — faster, more spatial, with better support for large schemas. Built to handle enterprise-scale complexity without losing the simplicity that made the tool approachable in the first place.

06 — Results

Impact

+30%

MRR growth directly attributed to enterprise feature set

US market

New geographic market unlocked — enterprise deals with US-based data teams

Enterprise
clients

Multiple enterprise contracts signed within 3 months of launch

07 — Learnings

Reflection

This project changed how I think about feature complexity. The temptation when designing for enterprise is to add more — more controls, more options, more configuration. What we actually needed to do was add the right constraints in the right places, and make complexity feel manageable rather than comprehensive.

The users who struggled most weren't new to data modeling — they were experienced engineers who'd lost trust in their own tool.

The governance workflow was the hardest part to get right — not technically, but conceptually. Early prototypes felt like bureaucracy. The breakthrough was framing it as a safety net rather than a gatekeeper: the goal is to catch mistakes, not slow people down. That reframing changed the language, the UI, and the default settings.

If I were doing this again, I'd start with system thinking much earlier — before wireframes, before flows. The biggest delays weren't design revisions; they were moments where we realised mid-sprint that a conceptual question hadn't been answered yet. More exploration time upfront would have saved weeks downstream.

I'd also involve compliance stakeholders from enterprise prospects earlier in the process. Their requirements shaped the final feature set significantly, and earlier access would have saved two rounds of design revision — and probably tightened the product scope from the start.

Scaling Data Modeling for Enterprise: From Chaos to Structured Workflows