How Stern Risk Partners went from locked-up Postgres to embedded analytics in weeks
The more I worked with it, the more I was just like, oh my God, this is so much simpler than working with Snowflake.
Pete Rafferty
Senior Software Engineer
Stern Risk Partners is an insurance brokerage that built a Ruby on Rails platform for managing insurance programs across 160+ properties. With their single Heroku Postgres database buckling under growing dbt jobs and ETL workloads, they migrated to MotherDuck and cut transformation time from 2 hours to 7 minutes—unlocking embedded analytics and a path to MCP-powered self-service querying.
Stern Risk Partners is an insurance brokerage that built a Ruby on Rails platform for managing captive insurance programs—essentially self-insurance pools where property owners pay premiums into their own accounts rather than external insurers. The platform handles premium syncing, enrollment tracking, and charge reversals for resident liability programs at student housing properties, integrating with 50+ property management systems (Entrata, RealPage, Yardi) across 160+ properties.
Everything ran on a single Heroku Postgres database: the Rails application, ETL jobs, dbt transformations, and analytics dashboards for their customer-facing application.
As the program scaled and became more data intensive, pain points compounded:
- ETL from APIs took 4-6 hours nightly and growing with each new client
- dbt transformations locked the Postgres database for 2 hours—users couldn't access the app
- Scaling up Postgres only added storage, not analytical performance
- A failed dbt run meant restarting from scratch and losing 2 hours of uptime
"We were going to run out of runway with our growing dbt jobs. Eventually we just weren't going to have enough time in the day to process all the data needed for all the clients that we had."
The New Architecture
Faced with a performance crisis, the team at Stern had to decide–either implement what they knew from previous roles (Snowflake), or evaluate other options. After seeing a writeup about MotherDuck online, they started an evaluation.
- Extraction: Property management APIs (Yardi, RealPage, Entrata) and the application Postgres DB export to CSV and Parquet files in S3
- Transformation: dbt runs on a MotherDuck Jumbo instance, completing the full build in 7 minutes
- Reverse ETL: Select production tables write back to Postgres via S3 so the Rails app stays in sync
- Dashboards: Omni connects directly to MotherDuck for customer-facing embedded analytics
Four service accounts handle different workloads at different instance sizes–a simple implementation of MotherDuck's hypertenancy model: ETL ingestion, production dbt on Jumbo, CI validation on Standard, and Omni for dashboards.
Because MotherDuck was so fast, Pete could iterate quickly on the dbt models themselves—investigating bottlenecks that were invisible when every run took two hours on Postgres. He optimized the dbt build down to 7 minutes, and a failed run now re-runs quickly instead of two hours from scratch.
Simpler Than Snowflake
Pete had years of Snowflake experience at previous companies and initially considered it for Stern Risk. MotherDuck won on simplicity:
"Snowflake's role-based access control turned into a nightmare at my previous job—managing all the different user accounts, the roles tied to those user accounts, what they could do at schema, table, and database levels. Not having to do that in MotherDuck has been a total game changer."
Service account tokens eliminated the complexity of managing login credentials and MFA for machine users:
"MotherDuck is great with the service accounts. There is no login for a service account. It's just a token. Tokening is just a lot simpler and a lot more secure."
Pete also considered self-hosting DuckDB, but managing infrastructure wasn't the job he wanted. MotherDuck had "all the bells and whistles we need to just get going very quickly"—service accounts, support, managed compute—without turning into a full-time ops role.
From Ruby Frontend to Real BI
Before MotherDuck, Stern Risk's dashboards were hand-coded Ruby on Rails views querying the transactional Postgres database. Beyond that, the company had essentially no business intelligence—no operational dashboards, no executive reporting, no centralized analytics.
With transformations running in MotherDuck, Pete connected Omni directly and deployed embedded customer-facing dashboards into the Rails app—giving property managers visibility into premium syncing, enrollment status, and charge reversals without hitting the Postgres database. A dedicated service account keeps dashboard queries isolated from ETL and dbt workloads.
The next phase is operational: dashboards for the account management team to catch syncing issues and charge errors before clients report them, plus executive-level analytics showing the overall health of the captive programs business.
Support That Ships Fixes
Migrating a production data stack as a one-person data team means support matters. Pete found MotherDuck's team materially different from what he'd experienced at scale with Snowflake—faster responses, and engineers who understood the problem rather than routing tickets.
"The support from the MotherDuck team has been really valuable. I definitely haven't gotten that level of support with cloud data warehouses I've used in the past. I heavily used Snowflake at previous jobs and the support definitely wasn't as responsive or as knowledgeable with addressing issues."
What's Next: MCP for Non-Technical Users
Pete already has MotherDuck's MCP server running and connected to his own instance, pulling insights from the warehouse through natural language. The next step is opening it up to the team—starting with a new operations analyst who may not know SQL.
"Having that MCP server will allow them to dig into the data and answer questions for themselves without having to write SQL queries or really fully understand how SQL works."
