GoodShip: Building an Analytics Agent for Global Logistics

When the Dashboard Becomes the Bottleneck

GoodShip's data is stored in Postgres. The analytics backend runs a lot of workloads on it. As the customer base increased, the response time increased significantly.

As queries grew more complex—joining late delivery records to financials, surfacing carrier penalties, running aggregations across years of operational data—Postgres started to break. Queries were taking too long to complete, leading to time-outs, such that for large historical queries, no results were returned.

Some of the larger datasets would include about 4 million records spanning three to four years. Not enormous by data warehouse standards, but enough to expose Postgres's limits for analytical workloads and degrade the end user experience.

The team started evaluating alternatives. ClickHouse was a contender, but the query dialect diverged from Postgres SQL in ways that felt unsustainable. Starburst and Apache Pinot required managing clusters—too many moving parts for a growing engineering team. MotherDuck offered a friendly SQL dialect, serverless infrastructure, and a pricing model that matched GoodShip's bursty usage pattern. The analytics migration solved the immediate crisis.

Laney: an Agent for Shipping Analytics

Laney is GoodShip's AI analytics agent that lets logistics customers ask natural language questions about their shipments, financials, and operations. MotherDuck's remote MCP server made it possible to wire up data access from Laney in days.

But building an agent that writes SQL against customer data raised the stakes on multi-tenancy. In Postgres, isolation was a WHERE clause—a tenant ID column on every table. "It's just a tenant ID column on the tables," explained Iku Kyogoku, senior software engineer. "I wanted more assurance that the agents could only access their own customers' data."

With MotherDuck's hypertenancy architecture, physical isolation became trivial: one service account per customer, one database slice per customer. The agent queries only the data that resides on a customer's compute node—it structurally cannot access another customer's data. More importantly, GoodShip can scale up individual nodes for their most important customers, without scaling an entire compute cluster. "Separating customers with hypertenancy makes MotherDuck secure by design for analytics agents. I love that," said Iku.

One Duckling Per Customer

The architecture GoodShip built reflects both the performance and isolation requirements:

• Periodic exports package each customer's data from Postgres into a dedicated MotherDuck database under its own service account
• Laney connects to each customer's isolated Duckling via MotherDuck's remote MCP server
• For user actions that need to take effect immediately—flagging a dispute, muting an alert—GoodShip uses DuckDB's Postgres extension to union real-time data from Postgres with the snapshot in MotherDuck

The agent stack is Node.js, Mastra (an open-source agent framework for Typescript), AI SDK, and MotherDuck's remote MCP. GoodShip had originally built their own lightweight agent connector before MCP was available. "It worked, but there were edge cases where the agent queried a big result set and just couldn't handle it." Their DIY implementation needed manual truncation logic, summarization steps, and constant maintenance as DuckDB evolved.

Switching to the MotherDuck MCP took less than a week. "It was just specifying the endpoint and the token—all the tools were registered into the agent and it was working." DuckDB query hints are baked in, and MotherDuck manages the infrastructure.

What Laney Made Possible

In production, the end user experience took a big leap forward. Queries Postgres couldn't return in sixty seconds before timeout now return sub-second through MotherDuck.

For agentic analytics specifically, latency matters more than it does for traditional dashboards. "The agent has to do one query, and then based on that, what else can it do? It's a very sequential step. The latency is important." Thirty-second latency per reasoning step doesn't produce a slow dashboard, it produces an unusable agent.

MotherDuck's serverless billing model fits GoodShip's usage pattern naturally. Logistics operators aren't in the analytics interface all day. They review data in the morning, then go to solve problems. GoodShip pays for compute when it's used, not to keep a cluster warm for idle tenants. "You can query an individual Duckling as much as you want: humans or agents. It doesn't impact other customers at all, which is amazing. I'm so glad MotherDuck came along."

Customers responded immediately. When Eric Dillon, GoodShip's VP of Engineering, described the reaction, he called it "rapturous." "Our customers are getting the answers they need instantly through the agents we've built on MotherDuck."

Laney went to production in January 2026. The team has since flipped over their entire reporting backend to MotherDuck, bringing low-latency analytics to their entire reporting stack.

Head over to goodship.io to learn more about how this team is building first-class experiences for freight orchestration and procurement.