Listen on
Many data leaders face a paradox: despite significant investments in cloud data warehouses, teams struggle with runaway costs, architectural complexity, and dashboards that fail to deliver real-time insights for critical applications. Traditional systems, often designed over a decade ago for large-scale batch processing, prove inefficient and costly for the majority of analytical workloads that demand low-latency, high-concurrency interactivity at the application edge.
This episode features Tino Tereshko, Co-Founder of MotherDuck and a former architect at Google BigQuery. Tino details why the fundamental assumptions underlying traditional cloud data warehouses are now outdated, often leading to expensive, over-engineered solutions. He introduces MotherDuck’s serverless analytics data warehouse, which leverages DuckDB’s single-node efficiency and a unique hybrid execution model to cut costs, simplify infrastructure, and enable new classes of interactive data applications.
The conversation explains how MotherDuck addresses the “hair on fire” problem of delivering sub-second analytical responses, often directly within the user’s browser. It highlights how this architecture reduces compute costs by metering actual CPU cycles and provides isolated serverless runtimes for every user, offering a stark contrast to legacy shared-resource models. Listen to understand how these architectural shifts transform both the developer and end-user experience.
Key Takeaways
The majority of analytical workloads achieve better cost and performance on single-node engines.
Traditional cloud data warehouses are often over-architected for most analytical tasks. Only about 1 in 3,000 queries across a system like Redshift truly need petabyte-scale distribution. DuckDB, running on modern, powerful single-core machines, avoids the costly ‘shuffle’ overhead of distributed joins, delivering superior performance for many terabyte-scale datasets at a fraction of the cost.
Deploying analytics to the browser creates real-time interactive experiences that redefine data products.
MotherDuck’s hybrid architecture places a DuckDB node directly in the user’s browser via WebAssembly. This allows analytical computations to run 0 milliseconds from the user on their own hardware, enabling 20+ frames per second interactivity for dashboards. This capability moves beyond the typical 5-second load times of traditional BI tools, creating entirely new product experiences.
Serverless pricing by actual CPU cycles fundamentally shifts data warehouse economics.
Unlike traditional cloud data warehouses that bill for cluster uptime and provisioned capacity, MotherDuck meters actual CPU cycles used by queries. This aggressive pricing model eliminates costs from idle time and incentivizes MotherDuck to make queries run as fast as possible, directly aligning its business model with customer performance and cost savings.
Local-first development with cloud consistency accelerates data engineering workflows.
DuckDB’s embeddable nature allows data engineers to develop, test, and debug SQL scripts and dbt jobs directly on their laptops. This local consistency with the MotherDuck cloud environment eliminates translation errors and the delays of cloud-only testing, making data engineering workflows more efficient and faster.
Related: CorrDyn helps clients architect data solutions that drive business value. We specialize in data cost optimization and data engineering practices that simplify complex systems. For applications requiring direct data access and new interactive experiences, our team delivers expert data API development. Learn more about our work with MotherDuck.
Full Transcript
Jason: Hi everyone, this is Jason, producer of Data BS. Today we’re joined by Tino Tereshko, co-founder of MotherDuck. We recorded this episode a few weeks ago, and since then Tino announced that he was stepping back from the company to focus on other ventures. He’s obviously still a massive supporter of the product, and during the interview with James, he shared a bunch of interesting insights on how the company is solving problems for its customers, and we had to share. Enjoy.
James Winegar: Welcome to Data BS, a show dedicated to tackling the big questions impacting the world of data and ML/AI without any of the BS. My name is James Winegar. Each week I sit down with guests from across the data ecosystem to unpack how they’re shaping their businesses or the businesses of others through the real-world application of data engineering, ML/AI, infrastructure, analytics, and more. No fluff, unfiltered but slightly edited to remove noise. This is Data BS. Let’s get into it. All right, we got Tino Tereshko here from MotherDuck, chief product officer, co-founder, head of product. I’ll let Tino introduce himself.
Tino Tereshko: For those who are not familiar, MotherDuck is a serverless analytics data warehouse. What it means is you put your data into MotherDuck storage and you use SQL to analyze that data. Things get a little bit complicated. The big vendors in this space are Snowflake, Amazon Redshift, Databricks, and there’s a large number of legacy vendors as well, like Teradata, the Oracles, and so forth. Why did we start MotherDuck in such a very competitive, very mature market? We saw a couple of trends emerge over the last few years. The big vendors have been around for 10+ years. They were architected 10 to 15 years ago. The landscape has shifted in a couple of ways. One is that hardware has gotten a lot bigger. When I worked on Google BigQuery, we were working with 4-core, 2 gigs of RAM machines. Of course we have to string 1,000 of them together to make anything happen. Now on Amazon, you can get 449-core machines, terabytes and terabytes of RAM. The size of hardware has dramatically changed. The other thing that we noticed a couple of years ago is this open source project called DuckDB. That’s why we have all the ducks around. DuckDB is amazing. It’s such a beautiful database. It’s fast. It’s probably the fastest database out there. It’s beautiful to use. It’s got a wonderful SQL that pushes the boundaries of easy use. A lot of the things that it’s introducing are being adopted broadly by the industry. It’s easy to get going with. You just do pip install on Python. But the thing that makes DuckDB unique is the fact that you can put it anywhere. It’s like SQLite. It’s an embeddable database. You can put it in a Lambda. You can put it on a VM. You can put it in R. You can put it in Python. You can even put it in the browser. We thought about that and we said, that’s a very meaningful change. Suddenly analytics can take place anywhere. Before DuckDB, you had to go to this big mainframe in the cloud called BigQuery or Snowflake and do analytics there. Now you can take DuckDB and put it on your MacBook. That M1, M2, M3 MacBook is really powerful. You get almost the same value. George Fraser, CEO of Fivetran, tested DuckDB on his M1 Pro. It’s not even the newest laptop, and it was just as fast as a $60 an hour data warehouse in the cloud. That’s a meaningful change.
James Winegar: When we think about DuckDB and the OLAP or analytical use cases, it has features that support it being fast on a single machine. The design mantra of DuckDB is on a single machine where I don’t have to worry about networking and coordination overhead, I can do things much faster. Because the machines have gotten so much bigger, we’re able to put the majority of our workloads against this local or in-process database. If we got something truly gigantic that actually needs that distribution, we can go do one-offs for that type of thing elsewhere. I don’t remember who did it on your team, but there was a post about how many queries are truly big data that get queried after predicate pushdown and all that stuff. It’s a fraction of a percentage.
Tino Tereshko: It’s 1 in 3,000 queries across all of Redshift. You’re absolutely right. One of the reasons why DuckDB is so efficient is because it’s single node. I worked on Google BigQuery, which is perhaps the most distributed system out there. It uses thousands of tiny nodes to get every query processed. We’re doing the opposite here. We’re saying DuckDB goes on a single VM on EC2, and they can be pretty beefy. Pick a join. The most expensive part of any distributed query, especially joins, is the shuffle. They used to call MapReduce little map, big shuffle, little reduce. Shuffle is the real cost that you pay in terms of efficiency, in terms of performance, in terms of cost of distributed processing. We avoid that in DuckDB because everything takes place in a single node. The join index is memory space that can be shared by both processes, by both sides of the table. There’s no movement of these hash maps. That’s where efficiency comes from. DuckDB is incredibly performant and query efficient. To your point about scale, what we’re seeing at MotherDuck is that the vast majority of use cases fit into single node DuckDB. But for specific use cases that are petabyte scale plus, even in those use cases, you almost never need to run large queries. Specific workloads, for example applications we can talk about, actually look like thousands of smaller 1-terabyte-sized workloads instead of one large petabyte workload. Because of the way we architected our system, that works perfectly well with MotherDuck.
James Winegar: We’ve been pushing some of these things within MotherDuck, and DuckDB has responded, allowing swap and things like that. But we also have better disks with NVMe happening. Not only is CPU and memory scale, but the disk has gotten faster than network because we’ve moved to flash storage or NVMe storage. Why pay the overhead of having to do the shuffle? Let’s talk about some use cases. There’s probably a wide variety of use cases that people are using MotherDuck for because of the flexibility it provides with the hybrid query engine. Let’s talk through some of those.
Tino Tereshko: You can think of MotherDuck users in two buckets. One is data practitioners, and the other is software or application developers. For data practitioners—people like data engineers, data analysts, those running data warehouses—MotherDuck is a good, fast, simple, very easy to use data warehouse. Generally, people are not unhappy with BigQuerys or Snowflakes, but there is pressure on cost for many organizations these days. There is pressure on performance. Many of these systems can be complicated because they’re built for the large enterprise with tens of thousands of employees. Identity and access management and RBAC can be complicated. We’ve simplified that path. We’re a very good data warehouse and very inexpensive as well. For the application software developer persona, a whole class of applications has emerged over the last few years. This is an application that has application-level requirements, like low latency and high concurrency. It performs analytical computations, so it looks like an OLAP system or a data warehouse in its requirements. It’s at the intersection of the two worlds, data and applications, and falls between the cracks because it doesn’t work well in application databases, like row Postgres transactional databases. It doesn’t work well in the data warehouse or most OLAP systems because of low latency and high concurrency requirements. What we’re seeing is these types of folks come to us and experience how fast MotherDuck is, experience the developer ergonomics and the other benefits. They really appreciate that. What you mentioned, James, that we haven’t talked about yet, is this hybrid system. I mentioned at the beginning that DuckDB can go anywhere. What we’ve done is we put DuckDB in a browser. Our UI application has DuckDB running in there. We also created an SDK where our customers (and that’s what James is doing as well) are putting DuckDB into WASM, which is WebAssembly. It’s an in-browser container. You’re able to put DuckDB in the browser itself and build on top of that. Now you have a storage and execution engine that sits 0 milliseconds away from your customer, and it’s their hardware. It’s already paid for. With DuckDB in the browser under the right conditions, you can achieve amazing performance. Because it’s 0 milliseconds away, if a query takes 50 milliseconds (which is not unusual in DuckDB), you can achieve 20 queries per second. If you’re building an application on top of this system, you can suddenly achieve 20 frames per second or above level of interactivity. You can have a slider or zoom in, zoom out capabilities in your application that are truly interactive. For analytical workloads, that’s never been done before. If you ask anyone who’s built a Looker, Tableau, or Power BI dashboard, if that dashboard takes 5 seconds to come up, they’re quite happy. That’s state of the art in 2024. This is embarrassing for analytics. Why do we have to give our CEOs and C-levels dashboards that take 5 seconds to calculate? That’s unacceptable. We’re talking about a whole new set of end user experiences that we’re enabling. These are 20 frames per second and above experiences. That’s magical.
James Winegar: I remember our first meeting where you tried to hide that away from me because it wasn’t quite ready yet. I was like, that’s what we need to talk about. Since then, we’ve gone through an implementation, pushing down aggregated datasets (not gigantic, but some) to the user and then allowing cross-filtering and similar interactions to happen within the browser experience. This enables them to interact and get answers to questions they’ve never been able to ask before. Historically, at least for the customer we work with, literally nobody’s been able to get at the data with that low-level or high-level fidelity that quickly. When we did a private release of the dashboard, people freaked out about it, honestly. It was because it didn’t exist before. The opportunity didn’t even exist before. The secondary option for us was to do Tableau OEM. It was substantially more expensive for a worse experience and a lot of infrastructure that we would have to manage. We’ve gone to MotherDuck. We don’t have to manage the infrastructure. We do some ETL from the transactional database into MotherDuck as the OLAP database, do some aggregation, and then the users are getting real-time data (relatively speaking for that market) that they haven’t been able to do before. It feels nice. For the most part, we’re still in the private beta release, and it’s going fantastic.
Tino Tereshko: It’s funny, customers such as yourselves experience this like a five-stage grief. The first is denial, then acceptance, and then you get to see it yourself—that you do actually get these amazing experiences, and they’re enabled by different architecture. We’re not just taking a database and putting it in the cloud. We are doing that, and it’s a serverless storage execution engine, but we’re also using this hybrid execution mode. As James said, we’re taking a node of our system and putting it in the browser. Now you have a MotherDuck node in a browser and a MotherDuck node in the cloud. In the cloud, you have more scale. It’s connected to the central storage system, to the keeper of business records. Locally, you obviously have the customer there. What we’ve built is this hybrid mode where these two nodes can talk to each other very intelligently. They can process queries together and push workloads from the cloud (which is expensive and slow, but more scalable) into the local environment. The local environment is smaller, but it’s 0 milliseconds away from the user and has many other benefits.
James Winegar: That segues well into how MotherDuck compares to BigQuery, Snowflake, and Databricks. We’ve touched on it a bit, but let’s be more targeted.
Tino Tereshko: Of course. There’s a couple of ways we differ. One is using this hybrid mode. We push workloads to the customer, and there you get meaningful efficiencies, cost savings, amazing performance, and overall different developer and end-user experiences. Two is, think of how you deploy a data warehouse these days. You deploy a big box, whether it’s called a cluster or a data warehouse, and you put a bunch of people into that box. They’re all rubbing elbows against each other. They’re all competing for resources. There’s contention. Also, it’s not necessarily efficient because what if only one user is using that giant box? You’re still paying for the whole box. Sometimes you might see a large customer—it could be the CEO, an external customer—who needs an isolated environment. You can’t deploy them into a shared box and share resources with other people for a variety of reasons because they’re important. So you deploy them into a different isolated box. That gets complicated at scale. These customer sizes typically follow the Pareto distribution, which means there’s always a long tail of customers and a small number of larger customers. You have to architect your system in this hacky way. It smells like MySQL of 2008, where you had these giant shards of MySQL. What we said is, this should be our problem, not the customer’s problem. We said every single identity in MotherDuck—every user, James, Tino, or a service account—gets its own isolated serverless runtime. They don’t have to manage it. It’s isolated. You don’t have to choose between bin-packing people or isolating them into their own runtime. It’s also very efficiently priced. You can have lots of these. For example, if you have 1,000 users or 1,000 identities in MotherDuck, each one gets its own isolated runtime. That is a very different model than taking one big box, a big mainframe, putting it in the cloud, and everyone sharing it together.
James Winegar: With our use case, if we put it on BigQuery (which would have been the more likely place to land it, just because of the data volume), I estimated it would be $100 a day or so. That’s what we’re spending a month with MotherDuck right now on that particular use case, because we pay by byte versus the utilization of the compute. I’m seeing the pricing model and how it has the serverless pricing model built into it. It’s actual capacity driven versus Snowflake’s model or Databricks’ model, where you can reserve the unit that might be short-lived, but you’re taking into account how much you used in this environment because you have your own efficiencies you can manage in your own infrastructure. When we think about the value proposition of MotherDuck, we talked about some cost aspects, but what we’re seeing is a lot of new use cases that didn’t exist before that you can start doing with MotherDuck. Most datasets are smaller. What else would you say is a big value proposition of MotherDuck?
Tino Tereshko: We’re backed by DuckDB, an open source project that has exploded in popularity these days. It’s catapulted up the DB rankings. The statistics we can measure around DuckDB’s popularity have gone through the roof over the last couple of quarters. Anyone can use open source DuckDB today. You can use it in a variety of tools. It’s like the Swiss Army knife of analytics. We’re a vendor that provides managed DuckDB. If you’re a DuckDB user, you can do whatever you want with it. But if you want a managed environment, administration, identity authorization, support, and a third-party ecosystem, we provide all of those things. But it’s actually a very different model than classic open-core companies, like Databricks, for example. Databricks has Spark and its own version of Spark. We’re actually separate companies, but we’re partners. DuckDB is owned by DuckDB Labs, which has its roots in academia in Amsterdam out of CWI. Their goal is to continue to increase DuckDB’s popularity as an open source project. They never intended to monetize it as a service. That’s when we came along two and a half years ago and said, we’ll partner together. We’ll have exclusivity. You’ll own a large percentage of MotherDuck, and you’ll help us build this managed service. It’s a very different model. We’re different companies, but our incentives are aligned in many ways. Everything we do about MotherDuck is in partnership with DuckDB. Because we’re running DuckDB in production with real customer workloads, we’re seeing many things where DuckDB can improve. We’re doing a lot of open-heart surgery on DuckDB itself to get it ready for the cloud world, which has slightly different dynamics than an embedded database. To directly answer your question, James, one of the things unique about MotherDuck is that we are a serverless data warehouse you can use in the cloud, but you can always fall back on open source DuckDB. There are many conditional benefits you get from that. For example, if you have DuckDB running on your laptop, you can connect to MotherDuck with a single line of code. Suddenly, your laptop becomes a node in our system. You can join data on your laptop with data in the cloud. You can push data to the cloud. You can download data locally. One of the interesting use cases, to your point, James, is that data engineers are increasingly using DuckDB on their laptops to do their development, to build their scripts, their dbt jobs, and SQL. When you have DuckDB locally, you write in DuckDB SQL, and then you push it into MotherDuck in the cloud. It’s the same SQL. It’s the same workloads. It’s the same data. This is also a net new thing that you can’t do with Snowflakes and BigQuerys because they’re cloud-only. They don’t have anything local.
James Winegar: The development experience of working with DuckDB and MotherDuck together is enhanced because you can suddenly do local testing and then push it up to production (or staging, or whatever). When you have a consistent workflow between local and your deployment environment, you don’t have to have translation or anything like that. A long time ago, I was working on something where we were using DuckDB as a local test and then had to do translation into BigQuery syntax so that we could at least bridge the gap, allowing people to work on some test cases locally before pushing into BigQuery. Eventually, people were running it in the staging environment because that was too painful for regular analysts to work on. Making everybody more efficient in what they do as a developer is also important. What types of organizations are you seeing using MotherDuck, and why is MotherDuck making waves with those organizations?
Tino Tereshko: That’s an excellent question. The way we’ve been thinking about the market is that Snowflake, BigQuery, and Databricks are going after the top of the market. They’re trying to sign $100 million deals because they have a lot of revenue pressure. That’s where the money is at. The bottom of the market, though—folks who have less data, who are paying less than $100,000 a year for the solution—Snowflake isn’t picking up their calls. If they are, they’re trying to get them to commit to a long-term contract. So they’re not feeling heard or supported. I saw this in BigQuery as well, because BigQuery has a lot of the smaller, tail-end customers—many of those folks. It’s like the silent majority, so to speak, in many ways. We’ve decided to start our company by addressing the needs of those folks. We are a PLG, which means a self-service, bottom-up product, meaning it’s incredibly easy to get started. It takes maybe 15 seconds to open a MotherDuck account and run your first query. It’s very low friction, very easy to use. We’re seeing a lot of that type of adoption. Of course, we provide a lot of support. We have experts who are essentially software engineers that can help you architect your system, and get you through some hurdles. We work very closely with these customers. We’re attracting smaller organizations these days, but we’re seeing more and more interest in SMBs and mid-markets—tech-native, cloud-native companies that are becoming bigger. These organizations are attracted to us for a couple of reasons. One is that they’re seeing the current data warehousing landscape is complicated and expensive. They want something simple and easy to use. They have small, collaborative teams and don’t want to spend a lot of money, so they go with us. The other type of company is attracted to the application workload that we have. That’s because for these workloads, for a number of companies, they’re actually P0 crucial workloads. If anything, these workloads are the company. The profile of this company tends to be more like a B2B organization—a cloud-native, tech-native company that produces data for their customers. Data is the product. Of course, one way you can give your customers that data is to drop it on FTP or S3. But increasingly, customers want this interactive experience. They’re building these interactive applications where you can drag and drop things, and do calculations on the fly. We’re seeing a lot of these types of customers come in through the doors because we’re an amazing option for that. For all the reasons we talked about.
James Winegar: Let’s get into more of the details about how MotherDuck came to be in terms of its technical architecture, because it’s not trivial to spin up databases or workers dynamically. There are some storage layer concerns there. I’m thinking you had to work with them because DuckDB was designed to run on somebody’s laptop, not thousands of them in a cluster, and manage it appropriately. You’ve worked on a lot over the last few years.
Tino Tereshko: You’re spot on. If you look at DuckDB, it’s a wonderful system, but it is designed around being embedded on somebody’s laptop or environment. It can be embedded in an application. So it makes many assumptions about storage and execution. For example, it assumes storage is readily available. It is mutable. You can read, write, and do whatever you want with it. You can use all the CPU you want, for example. The other assumption it makes is that it’s a single-player system. It doesn’t even have a concept of a user, identity, sharing, RBAC, or anything like that. No access controls, no IAM. It has been a challenge for us to bring it to the cloud because there’s a whole other set of requirements. Multitenancy, separation of storage and compute. The compute needs to be scalable, to your point. We’ve worked very closely with DuckDB over the last couple of years to both change how DuckDB works under the hood and to make its internal APIs more modular and extendable. Of course, we took advantage of those changes inside DuckDB to modify the storage system it uses, enabling things like time travel, snapshotting, and branching. This enables separation of storage and compute. Of course, on the compute side, we’re running DuckDB in production. We’re using DuckDB in an environment where data is shared between users. We have multiple users accessing the same data. So the compute has to be thought of very differently as well. Obviously, we’re running DuckDB in production. We have thousands of users, and they’re battle-testing the system for us, including you, James. Sometimes you’ll see a query that fails, for example, or takes a bit longer than it should. We have a direct line to DuckDB. We’re giving them lots of this information. DuckDB, in combination with MotherDuck, has improved so quickly that in June it reached 1.0. They went general availability. Before 1.0, folks would complain that DuckDB would run out of memory. It would get an error, something would happen. It was a stable system, but you could get it into a bad state every once in a while. Since 1.0, that conversation has stopped. It’s a very stable system, very performant. It’s reached maturity rapidly.
James Winegar: We’ve been working with your team closely on some of our workloads. When we’ve been going through how to make DuckDB do things more effectively, the turnaround time, and the partnership between MotherDuck and DuckDB Labs is good, honestly, in my opinion. We’re stressing the system. By stressing the system, many other people have interesting use cases. They’re stressing the system in different ways. Now, you take that as a feedback loop. You get significantly more information about what’s not working because you have MotherDuck in play now, too. That’s feeding your team and DuckDB Labs team with feedback like, ‘We’re failing on this use case.’ For these types of use cases, what can we do to deal with the storage system more effectively, or how can we work on the query optimizer so that it does something a bit smarter here because we have statistics or similar data? I think that information itself has probably driven DuckDB Labs, or DuckDB in general, to be more stable.
Tino Tereshko: Absolutely. One thing I want to mention is that I worked on Google BigQuery, which is a very complicated system with several hundred engineers working on it. Many of the improvements you want to make to the underlying execution engine—say, improving the performance of a specific type of query—would take a significant amount of engineering work to complete. It could be multiple engineering years, if not decades, to get anything serious done. If you look at DuckDB, it’s a 25-megabyte binary. It’s very simple. Underneath the hood, it’s beautifully designed and very extendable. What happens is in academia, a new research paper might come out saying, ‘Here’s a new type of filter that will improve window functions.’ DuckDB can implement that idea and test it within a matter of days, if not weeks, and adopt the newest things happening in the industry. You don’t have to believe me when I say that. You can look at the code, and you’ve contributed to the code yourself. Also, a blog came out a couple of months ago from DuckDB that measured the performance improvements over the last couple of years. I’m not exaggerating when I say that virtually every release (which happens about once a quarter), many types of queries would improve by an order of magnitude. For example, in the last release, window functions improved by a factor of three. With the previous release, aggregations improved by a factor of three. You’re seeing this dramatic improvement in performance, and it wasn’t a slow system in the past. Objectively speaking, if you look at DuckDB’s performance today, it’s probably faster than anything else out there for the right conditions. It’s only getting faster, very rapidly.
James Winegar: As long as you can fit it in memory on the machine, you’re going to have a good time.
Tino Tereshko: And even out of memory these days.
James Winegar: It’s very nice. Our use case has quite a bit of swap because the cardinality of the aggregation is very high. Because of that, we swap a decent amount, but we’re running queries in 10 minutes that I would have expected to take weeks if I tried to run it on Postgres (which is not an OLAP system, but it’s where we move the data from into MotherDuck). If I tried to run that query on Postgres, it would take a couple of weeks to run, because it has to go literally row by row. It’s columnar, so you can now do these aggregations more effectively. There are a lot of things where dbt jobs take 15 minutes to go through, and it’s a terabyte-sized dataset. We’re doing probably a couple hundred different types of aggregations, and it’s very stable for that workload. As soon as we get through some performance tuning on one spot in the DAG—you go from raw to some cleaned-up version of the table that takes most of the time. All the aggregation work then typically takes a few seconds; we just have hundreds of them. So we’re just going through that workload. I’m excited for DuckDB’s handling of larger-than-memory datasets, but also for its efficiency on that single node. There’s a lot of give and take between what you swap and what you try to keep in memory. The information MotherDuck will provide, because you have thousands or millions of queries executing, will help guide the statistics. For example, ‘These are the types of queries causing problems.’ You can handle that more effectively.
Tino Tereshko: We haven’t even pushed the boundaries of what’s possible. The largest hardware we currently run on is 64 cores and 56 gigabytes of RAM. There are machines that are four times that size. I think 192 cores and a terabyte and a half of RAM that we haven’t had the need to test. But when the time is right, we’ll test them. I think then you probably won’t even need to use swap for some of these.
James Winegar: For our dataset, for instance, there would be no swap in that use case. We tested, for example, I have a server with roughly the same specs that we ran it on. We thought, ‘Okay, this runs.’ But when we go to swap, we’re having an issue. I think the turnaround when we worked with your team, and us getting through everything, working with DuckDB, took about two days. It’s very effective, and you’re doing good work, trying to get people to realize the use case when things are happening. Can you talk more about your experience from working at BigQuery and Firebolt that’s helping you design MotherDuck to meet users’ needs?
Tino Tereshko: Of course. BigQuery and Firebolt are very different organizations in many ways. A few things I’ve done in my everyday life are important. One is always having very strong principles. I’m a product professional, so I have a small set of strong product principles that I rely on because there’s a lot of ambiguity. There are always disagreements. There are different ways of doing things. Falling back on those principles becomes important. Things like ‘the customer’s always right,’ ‘user experience matters,’ ‘go find pain’. Things like that are meaningful, and that stays consistent no matter what you do as a product professional. The other important thing I learned at MotherDuck (that I didn’t have to learn in BigQuery) is that if you don’t do something at a small company, it’s not going to get done. There’s no delegation. Within reason, of course. You can’t sit around and say, ‘I’m an executive; I’m only going to tell other people what to do.’ No, you actually have to get up, off your butt, and hustle. It makes it fun. You can’t get caught up in politics. You’re not caught up in the bureaucracy and the big machine you’re trying to move. You’re innovating and trying to get stuff done.
James Winegar: It’s the difference between a big company and a startup. In a big company, you’re spending more time getting alignment and ensuring everyone agrees, which is an effort in itself because there are different competing outcomes people are trying to reach for. Maybe you’re even directly competing against each other without realizing it. In startups, the executive team is more of a visionary, but they also know the most. So, in terms of ‘We need to do this, and here’s why, and here’s the outcome we’re trying to get to. Who needs help? Let’s get this thing across the line.’ I personally like the startup environment a lot better. I’ve been running my own thing for almost ten years now. Obviously, I like that freedom too.
Tino Tereshko: I would agree with you on that one.
James Winegar: At the same time, many of our customers are bigger organizations. You have to know how to navigate that. From working at Google, you probably gained a lot of experience about how to communicate with these stakeholders who are looking at MotherDuck, and what decision criteria they’ll have for MotherDuck versus Snowflake, BigQuery, or similar.
Tino Tereshko: One of the principles is finding meaningful customer pain. Acute pain. One of our investors, Jon Turow from Madrona, likes to tell a story: Imagine somebody walking down the street whose hair catches on fire, and all you have is a tennis racket. They’ll buy that tennis racket from you and put out the ‘hair on fire’ problem because it’s not perfect, but it will do. The problem is very urgent. This is the ‘hair on fire’ problem. If you find a ‘hair on fire’ problem, customers will work with you. They will have more patience. Overall, you can come together to put out the fire, so to speak. If you don’t have a ‘hair on fire’ problem, it becomes a bit more difficult. We feel we have encountered that problem with this application workload, and we have a beautiful solution for that. We’re seeing that in our conversations with customers.
James Winegar: I definitely feel that’s the ‘hair on fire’ tool or solution. As we were talking about earlier, there’s literally no other option out there. You pretty much need that bridge, the hybrid query engine, if you want to push it into the customer experience. I don’t know anything else that has a hybrid query engine able to go local to the user. It also improves the developer experience with local DuckDB test cases, then going up to your production or staging environments. You’ve solved not only for these unique new use cases people want to achieve, but you’ve also solved a lot of efficiency for the data engineer, analyst, and so on, to be more productive. You’ve made people more productive, enabled new use cases, and are designing what needs to happen to support more and more of those use cases as you go forward. It’s probably worth talking about MotherDuck’s pricing philosophy, given that it’s a serverless data warehouse. If you compare it to other data warehouses, you buy a box, even if it’s for a couple of minutes, and you still bought a whole box. What differentiates MotherDuck in terms of its pricing philosophy?
Tino Tereshko: It was Jeff Bezos who said, ‘Your margin is my opportunity.’ As newcomers, we have that luxury. Our lack of revenue, so to speak, is a strength of ours. We don’t need to protect that revenue. The modern data warehouse is priced as a luxury good. Their margins are very good. What we’re seeing in this market, thanks to many open-source initiatives such as DuckDB, is rapid commoditization. The big vendors are undergoing pressure from the financial side. Of course, the current environment—with interest rates no longer zero and a shift away from data being the innovation story to AI being the innovation story—all these things combined put a lot of pressure on organizations not to have a runaway data warehousing expense. What we said is we want to be priced right. We want to be priced fairly as well. Storage and execution are typically how these systems are priced, and execution is typically where most of the cost lies. Let’s focus on that. Storage is S3 prices—you pay per gigabyte stored. But on the execution side, as you mentioned, the typical vendor charges for the cluster. It charges for how long that cluster is up. There are typically settings for when the cluster shuts down. Almost always, there’s a lot of idle time in that cluster. If the cluster is up, you’re paying for that cluster no matter what, and you’re paying for a lot of time with that cluster being up while doing nothing. We said that doesn’t feel right. What we do is we meter the actual CPU cycles used by your queries, and we charge for that. That’s interesting because it creates a great incentive for us to accelerate your queries—to ‘get them out of our system.’ Because whether a query took ten seconds or ten milliseconds, the CPU time is essentially the same. We don’t have this perverse incentive in the space not to improve performance, because then you lose your edge. We have an incentive to make performance as good as possible—best performance possible. We’re charged for CPU cycles. For example, if a query does a lot of I/O at the beginning, then a lot of CPU processing to aggregate something, and then a bunch of I/O before sitting around waiting for I/O to open up—for us, you’re only paying for the CPU portion of the query. I’m simplifying, whereas with every other vendor, you pay for the whole thing. To your point, we’re incredibly aggressively priced. People are shocked at how inexpensive MotherDuck is for them.
James Winegar: The I/O time for you isn’t expensive either because it’s just grabbing some stuff off S3. So it’s a single-threaded thing happening versus DuckDB going to work, and suddenly you’re using 64 cores, full bore. So it’s pricing fairly with the CPU utilization of the query. Versus, you had a bunch of idle time because you had to read, say, 500 gigs into memory first. That didn’t cost anything, at least in the way your system is architected, because it’s not ‘spin up a new box to support it with an isolated workload’ or similar.
Tino Tereshko: Exactly.
James Winegar: The cloud efficiency model is baked into how the system is architected. Everything is elastic. The ideas of scalability are built into the design, to the point you made earlier: the original systems were designed 10 or 15 years ago. They have the limitations of systems designed 10 or 15 years ago. We’ve advanced a lot in terms of how we do things.
Tino Tereshko: For example, the way our instances run is that we containerize them and added auto-scaling. If you’re not using MotherDuck, James, we keep your instance idle at scaffolding size, which is a couple hundred megabytes of memory, with no CPU usage. Then if you log on to MotherDuck and say, ‘I’m going to start querying,’ we’re able to change the container size almost instantly. It takes milliseconds. It’s a change in alloc. This auto-scaling happens so quickly and efficiently that the technology we’re working with and the way we’re architected affords us to be this inexpensive because we can be very efficient in that matter.
James Winegar: Milliseconds versus minutes in terms of your scaling. So you don’t need to charge for the minutes anymore. You focus on the execution time.
Tino Tereshko: Exactly.
James Winegar: All right, Tino. Where can people learn more about you and MotherDuck?
Tino Tereshko: If you’d like to learn more about MotherDuck, you can go to motherduck.com. You can sign up in 10 or 15 seconds. As I mentioned before, you can start querying your data, or public data. You can start querying data that’s on your laptop. If you have CSV files or even Excel files on your laptop, you can bring them into MotherDuck and query them. We give everyone an unlimited 30-day free trial. We’re not even going to ask you to put down your credit card, and we have a startup program. If you are a VC-funded startup, you can sign up and get a year of MotherDuck for free. There are many different ways to interact with us. It’s super easy to get going, super inexpensive. There’s not much reason not to.
James Winegar: All right, motherduck.com, and go forward from there.
Tino Tereshko: Awesome. Thanks, James.
James Winegar: That’s it for this episode of Data BS. If you enjoyed this episode, make sure you subscribe wherever you listen to your podcast to not miss the next one. This episode was sponsored by CorrDyn, a data consultancy that helps organizations unlock the power of their data. If you have a data challenge, we can help. Visit corrdyn.com. C-O-R-R corrdyn.com to learn more. See you next time.
