Duck out of Snowflake Summit in SF from June 1-3Join us at The Dive

START FREE
BACK TO VIDEOS
WebinarMotherDuck FeaturesAI, ML and LLMs

Building a Data Product on MotherDuck: PriceMedic's Path from Raw Data to Revenue

2026/05/12

TL;DR: PriceMedic is a 4-person healthcare pricing data company. They replaced their AWS query stack (Athena, Redshift, SPICE) with MotherDuck, cut query times by 14x, saved roughly $20K/month, and built a hypertenancy architecture that gives every customer isolated compute. They then used MCP and Dives to collapse dashboard creation from tens of hours to under 30 minutes.

The data and the team

PriceMedic sits on a petabyte-scale data lake of US healthcare pricing data: tens of thousands of procedures, thousands of insurance companies, and millions of providers. Co-founder Josh Nakka runs the platform with a 3-person engineering team. Their customers are healthcare provider groups setting procedure prices, and employers shopping for better deals on care.

Why they left the AWS stack

The original stack was native AWS: an S3 Parquet data lake with Athena for ad-hoc petabyte queries and Redshift powering customer-facing analytics. Two problems pushed them off it. Athena was too slow for anything interactive. Redshift cost too much for their actual read patterns, with cold-start latencies above their 7-second tolerance. They were paying for both engines and still not hitting the bar on user experience. This kind of bloated cloud data warehouse spend is common in analytics shops.

The hypertenancy architecture

Rather than running one big shared cluster, PriceMedic gives every customer their own MotherDuck service account. Each customer's queries hit isolated compute against the same S3 source. This sidesteps the noisy-neighbor problem without provisioning a warehouse per tenant. The S3 lake stays the single source of truth, and the compute layer on top is swappable. That separation is how they replaced Athena and Redshift with MotherDuck without touching the lake.

MCP and Dives in the sales motion

The biggest unexpected win was the MotherDuck MCP server paired with Dives. Building a proof-of-concept dashboard for a prospect used to take an engineer several hours in their BI tool. Now an AE can prompt Claude with a prospect's question, MCP runs the queries against the lake, and Dives renders a working app in under 10 minutes. The same prompts that worked in sales started getting embedded into the product as customer-facing views.

What they ship to customers

PriceMedic's first contract with Dives as the primary customer interface is live. Customers can ask their own questions through a governed MCP layer Josh's team built on top, with each customer's data isolated by service account. Internal dashboards the team uses day-to-day are managed via CI on the underlying Dive code.

FAQS

Athena took over ten minutes on interactive customer queries, which was too slow. Redshift got expensive under the read-heavy workload and still couldn't hit PriceMedic's sub-7-second cold-start target. When they pointed MotherDuck at the same S3 Parquet lake, query times dropped 14x and they saved about $20K a month on infrastructure. The data in S3 didn't change, they just swapped the compute engine sitting on top of it.

Each customer gets their own MotherDuck service account with isolated compute, all reading from the same shared S3 data lake. No noisy-neighbor problems, no need to spin up a separate warehouse per customer. Because S3 stays the source of truth, PriceMedic can swap out the query engine (Athena, Redshift, MotherDuck, whatever) without touching their storage layer. See data lake vs data warehouse vs lakehouse for how this pattern works.

AEs prompt Claude with a real prospect question, the MotherDuck MCP server queries the lake, and a Dive renders a working data app in under 10 minutes. That used to take an engineer several hours, building a custom BI dashboard for each prospect. Some of the Dives created during sales calls actually became the customer-facing experience after the deal closed.

Four people, three of them engineers. They stay small by automating their ingestion pipelines and building data flows that self-recover when things break. Infrastructure shouldn't eat engineering time, so most of their work goes into the product and the analytics customers actually see.

Related Videos

View all