Pod Insights a16z Podcast The Great Data Debate About this episode Lakes v. warehouses, analytics v. AI/ML, SQL v. everything else... As the technical capabilities of data lakes and data warehouses converge, are the separate tools and teams that run AI/ML and analytics converging as well?
Transcript Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:00 Speaker 00 Hi and welcome to the Great Data Debate. I'm Doss and this is the A16Z Podcast. Today's episode is all about the debates happening around the modern data stack. Lakes versus warehouses, analytics versus artificial intelligence and machine learning, SQL versus everything else, and more. For other content from our series on modern data businesses, including example blueprints we've shared and a podcast with Databricks that traces the history and evolution of modern data architectures, please see a16z.com/moderddata. The conversation in this podcast was originally recorded as part of the Modern Data Stack Conference hosted by Five Tran. It's a spirited discussion with A16Z general partner and pioneer
0:44 Speaker 00 of software-defined networking, Martine Casado, and four founders who are building different parts of the modern data stack. Bob Muglia, the former CEO of Snowflake, Michelle Ufford, the founder and CEO of Notable, Tristan Handy, the founder of Fishtown Analytics, as well as the leader of the Open Source Project DBT, and the discussion's moderator, Five Tran founder, George Fraser, whose voice is the first you'll hear.
1:08 Speaker 01 All right. So I'm going to go ahead and kick this off with a spicy topic, I think, at least spicy in this crowd, which is data lakes. So data lakes is a blurry term used by different people to mean different things. But for the purposes of this discussion, let's define data lakes as tabular data, so tables, rows and columns, stored in an open source file format like Parquet or ORC in a public cloud object storage like S3 or Google Cloud Storage. So in a world where we have data warehouses that use object storage to store their data and give you some of the advantages of data lakes, do
1:50 Speaker 01 data lakes still have a place? Let's start with you, Martine. Does the data lake have a future?
1:55 Martin Casado? One of the biggest policies that we do as an industry is we look at an architecture and we're like, oh, that can do all of these things. Therefore, it will be pushed into service to do all of these things. And that's just not how technology evolves. We make decisions in the design space based on the primary use cases that technology is being used for. And if you look at the use cases that data warehouses are being used for, they're largely driven by analytics, which is a certain workflow, it's a certain query pattern. And if you look at where data lakes, it's actually quite different. They tend to be more unstructured data, focused on operational AI, compute intensive. And so if you look at the respective technologies, they're just being optimized in this massive design space for different use cases.
2:38 Martin Casado? Architecturally, sure, they can both do what the other one does. But in the end, you've got products and companies optimized around use cases. And I think the operational AI use case is a larger one and it's growing faster. So actually, I think over time, you can argue that it's the data lake that ends up consuming everything, not the data warehouse.
2:56 Speaker 01 You're just trying to provoke Bob Martin.
2:59 Martin Casado? He's defeated. You're watching Bob's face.
3:03 Speaker 01 All right, Bob, let's hear from you. Data lake doesn't have a future.
3:07 Speaker 03 No, I see these things very largely converging onto a relational SQL-based model. And five years from now, data is going to sit behind a SQL prompt and SQL data warehouses will replace data lakes from the perspective of storing structured and semi-structured data. The cloud SQL data warehouses already do everything that is necessary. And there really is no reason for people to have a separate data lake, except for historical precedent. A lot of companies come from environments where they had a lot of semi-structured data in a Hadoop environment, and having a data lake is a natural transition. And in a sense, the data lake, which is really S3 storage, together with a wide variety of any tools you want to put on top of it, is a very generalized platform.
3:52 Speaker 03 But over time, infrastructure evolves to take on more and more of the use cases. SQL relational data warehouses have evolved to the point that for structured and semi-structured data, storage and query, they subsume all of what needs to be done pretty much today. What remains is images, video, documents, PDFs. Now, I don't call that unstructured data. I think that's a misnomer. There is no such thing as unstructured data. All data has structure of some kind. Structured data is tables, rows and columns. Semi-structured data is like JSON, it's hierarchical in its nature. And I think there's a third category of data, which is what I call complex data.
4:34 Speaker 03 Images, documents, videos, most things that are streaming fall into this category. And more and more, machine learning can be applied to the contents of those data sources that turn it into semi-structured data that can be used for building complex data applications and for doing predictive analytics. So what's missing in the case of the data warehouse today is the support for complex data. But that's gonna come. That's called a feature. Can you imagine if you could transact, fully transact, all of these types of images, videos, and things, together with any source of semi-structured data in a data warehouse? The applications that open up are remarkable, and that's gonna come in the next two to three years.
5:14 Speaker 04 I could see images being easily retrieved from the database, but do you actually see all of the image processing or the video processing taking place in the database as well?
5:20 Speaker 03 Not with SQL. SQL can't do that. So you'll use procedural logic in Python or something else to do that, at least for now. In the long run, relational will win too, but that's probably more like eight to 10 years away.
5:33 Martin Casado? I think we've been waiting for that for 40 years, Bob.
5:35 Speaker 03 Right, right, right. We still need to be from Tristan. If you look, navigation un-hierarchical in the 1980s got replaced with SQL. OLAP got replaced with SQL over the last 10 years or so. We've replaced MapReduce with relational. So all of these things, relational always wins.
5:50 Speaker 04 Well, relational wins for the actual retrieval, but what about the processing, the technology that you need to process images is fundamentally different than you do to retrieve data.
6:00 Speaker 05 Tristan, what are your thoughts on this? So I completely agree that SQL is going to dominate data processing, at least a very large chunk of data processing. But there's different APIs that the data lake and the data warehouse expose. There's the file storage layer. And for a lot of reasons, I believe that an organization will store their files one time. You will not have a data warehouse copy of the file and a data lake copy of the file, which in some architectures today, that's what you see. And so that requires you to have an open source file format that is shared between your data warehouse use cases and your other use cases. Above that, you have indexing and metadata that is a core part of the data warehouse, but it's also a core part of the data lake.
6:45 Speaker 05 I think those have to also start to converge so that different use cases can take advantage of the same stuff. And then you have the SQL prompt. And maybe at the SQL prompt layer, the data warehouse dominates, but I think you need to allow different access patterns as well because one closed source firm is never going to accomplish literally all data processing use cases in the world.
7:03 Speaker 03 All of these things should interoperate in an open source and an open format way. But the issues of format have kind of gone away because you can input and output any kind of format and export into any kind of format very easily. The question is, what are the operations that actually need to be reformed against data that sits in a data lake? And today, anything associated with complex data, the data warehouse can't help you. And so there's a huge reason to have a data lake today. In 2025, I don't think so. I think that we really have five platforms being created globally, Snowflake, Databricks, and then the three clouds. Both Snowflake and Databricks, while they will come from very different places, Snowflake will always be SQL and declarative in its approach. And Databricks certainly historically has been procedural and code-based.
7:47 Speaker 03 So it's a version of SQL versus code in some senses. And I think you'll see both companies and pretty much everybody else in the industry offering both within their platforms.
7:56 Martin Casado? So you've got two technologies that start with different use cases, somewhat different architectures, but they're clearly going into a converged point, which is you have some declarative something and you have some procedural something. And like whether one's on top or the other, at the end of the day, they can both do both. But in the meantime, you have this decade-long journey. And in that decade-long journey, there is an architecture that's optimized around use cases. I mean, the amount of trade-offs and decisions you make when building one of these systems is...
8:24 Speaker 05 Yeah, like Timescale DB has very different characteristics than Snowflake. And they are characteristics that are optimized for a workflow.
8:31 Martin Casado? Yeah, entire companies focusing on different points in the design space.
8:36 Martin Casado? With different optimization parameters. It's actually the use case that drives the technology because of all of the gravity around it. And so, again, if it turns out that AI ML and an operational use is growing quicker, which it seems to be, seems that's more going to dictate the technology from an architectural standpoint.
8:55 Speaker 05 Martin, you've said a couple of times now that the AI ML space is appearing to grow faster. I've actually not heard that assertion before.
9:03 Martin Casado? Terrifying. So broadly, two use cases, right? There's the analytics use case, which is driven by queries and dashboarding. The other one is creating a complex model from a data scientist and then serving that in production. That does things like wait time prediction, that does things like fraud detection, that does things like dynamic pricing. These are folks in our building like complex models on existing data and then coming with bespoke way of serving that. That is very clearly now turning into a pattern that's being served by a data lake. Now, it's on a much smaller base, but if you actually look in the industry, it's a very rapidly growing use case.
9:36 Speaker 01 Michelle, you've spent time in both the data science community and the analytics community. And notebooks in many ways are the place where these things sometimes come together. I'm curious to hear your thoughts about how the two stacks have evolved. And maybe they're converging, maybe they're building each other's features and getting more similar. But where does that take us? Do we still have two stacks, five years hence?
9:58 Speaker 04 I think we're going to continue to see greater and greater specialization because we're not going to have the ability or the budget to hire enough data scientists. And so those stacks are going to continue to evolve and it's going to be specialized based upon what it is that they're trying to do. The data lake will have a place, your images, your web storage, all of those things are probably going to remain in the data lake and have a home there for a long time to come. I just think it's not going to look like how it looks today. Today, it's just been a lack of understanding around what data do we really need to collect? We went from one extreme to the other. We weren't collecting any data. Now we're collecting everything because we don't know what's valuable. And the reality is that's not necessarily a good idea either. The movement of data, I think we're going to see that stop. But format is going to be really important.
10:40 Speaker 04 We need that interop because reprocessing data at scale is just, it's cost prohibitive. It's time prohibitive. It's not something that we want to do if we can avoid it. And I think you're going to see decentralization here at the lower levels where you've got either the business units embedded or you've got your new product teams, you've got your data science teams embedded in those product teams. You're going to need a unifying layer at the very top in the form of technologies that make it easier for everybody to query or be able to serve. Information, I think that the notebook is probably the best suited for that because it does have the the language agnostic approach. You can see the ability to look at both data and code and have all of that context, that rich business context, the visualizations. We're going to see that evolve as this modern data document. And we can use that as part of our unifying layer because your data scientist can then work with,
11:24 Speaker 04 or your data analyst can work with SQL, but we can, at the end of the day, really hide all of the code and really get to what is the business implication of these things that we're doing.
11:34 Speaker 01 So this really brings us to the second major topic that I wanted to discuss, which is how do we bring the machine learning, Python, Scala world and the analytics SQL BI tool world together. There really are two stacks and two communities who sync the exact same data sources to Delta Lake and to Snowflake, simply for operational reasons. There's not a fundamental technological reason, but it's just the way the tooling has evolved. It's too inconvenient to cross that boundary. And there's essentially three visions of that world. One is that you're going to put machine learning into SQL. And probably BigQuery is the furthest along in pursuing this. You basically create a bunch of UDFs that do your linear algebra stuff.
12:19 Speaker 01 The other is more the Databricks vision where you put SQL into Python or SQL into Scala, and you use data frames to do that. And then there's maybe a third vision where you use Arrow, the interchange format, and everything can just talk to each other and you can arrange it any way you want. Which of these visions do you think is going to win?
12:41 Speaker 04 What I would like to see win is something like Arrow so that you have the interop. You're going to see machine learning moving into SQL because you're going to have data engineers who are perfectly capable and have the need to do some anomaly detection or some logistic impression. It's within their ability to do that. Feature engineering is just another data transformation for them. But they don't have the same background in stats and so they can only take it so far. And then you're going to see on the other side of the spectrum, your data scientist where they have all of this really great math background and they understand how to do more advanced deep learning, but they don't have the technology skills and SQL is the most successful language for working with data. And so you're going to really see both of them really become capable of supporting both use cases. But ultimately, you'll continue to see specialization here where
13:24 Speaker 04 the things that you want to do if you're trying to do deep learning are just fundamentally different than the types of things if you're just trying to do predictive models.
13:30 Speaker 05 I think a lot about the Arrow version of the world and I think that that will end up in the fullness of time dominating for the same reason that Martinez has been talking about that tools end up evolving to the personas that they serve and the use cases that they serve. I want to do all the data prep and feature engineering and then I want machine learning models to be trained on top of that. People do that certainly, but the fact that the infrastructures to do those two different things are generally separate creates this big slowness. It's a purely a technical slowness and Arrow doesn't solve all of that. Arrow certainly helps, but there's dumb things like the servers that do those things are in different clouds and the interchange fee, what do you call them interchange fees?
14:11 Speaker 01 Egress fees.
14:12 Speaker 05 Egress fees are expensive.
14:14 Speaker 01 They're criminals. They're not just expensive, they're ridiculous.
14:17 Speaker 05 Right. As more people do this, it's going to become smoother. They're going to become more localized.
14:21 Martin Casado? At the end of the day, there's a reason why you've got multiple languages and it's not because one is turn incomplete and the other isn't. And the reason is, is because people build their entire workflow around languages and all of the tools. And so you're going to have a heterogeneous fragmented system. And so therefore you do need to have open interfaces.
14:39 Speaker 03 Bob? I'm a big believer at this time in the approach of having multiple systems that interact with common formats. Arrow is a huge step forward for that, not just because it's an efficient format, but because it provides a consistent in-memory layout for people to do advanced analytics in their Spark environments. And it's the way the world is working right now because most customers actually have a data warehouse and an analytics platform separately and they are connecting them together. Now, I'm the radical, however. I'm going to continue to be the ultimate radical and declare that the approach that we're taking today in terms of machine learning is still roughly the approach of the internal combustion engine in the automobile. And the approach that's happening where Arrow
15:21 Speaker 03 ties together those predictive systems together with declarative databases, that's really the creation of the hybrid or sort of the Prius era. Hybrid will dominate for the next, say, three to five years. And you will see hybrid systems being built by every major vendor. And so all of them will have a full predictive stack. And a full declarative relational SQL stack built in using some kind of interface like that. But that's only until relational actually solves the broader set of problems.
15:51 Speaker 01 Does that mean that you'll be using SQL functions?
15:54 Speaker 03 No.
15:55 Speaker 01 Predict X?
15:55 Speaker 03 No. Ironically, I think that while SQL will dominate well into the 2030s for doing data modeling and data transformation, there's another step beyond that, which is business modeling. And that needs to be represented in a knowledge graph. Knowledge graphs are how we'll do predictive analytics in the 2030s. And what needs to happen is a whole new generation of data system that's based on relational knowledge graphs to create that.
16:20 Speaker 01 Michelle, you brought up a term earlier that I wanted to follow up on, which is data mesh. And I wonder if you could define that briefly for everyone, because similar to data lakes versus data warehouses, there's a question whether going forward, that's more of a historical phenomenon or an actual good architecture that we want to continue.
16:39 Speaker 04 Data mesh is really a concept of decentralizing the data processing and the ETL and analytics into each individual business unit, and then having some sort of unifying solution at the top. And to do this all requires having specialized data teams, having specialized roles, having infrastructure as a service available to them for data processing, and then having some sort of overarching standards board, almost like a federation of your data engineers, to ensure that all of your ETL looks consistent. So that as you are trying to do data retrieval and some sort of common query tool, you'll have that familiarity that you need. We are going to see things like Arrow really come to the forefront sooner
17:21 Speaker 04 or later. I think customers are going to demand it because of all of the challenges that we're currently having. We've got all the cost of the storage and the processing. Your teams that are trying to do the processing don't have the business context that they need. And so as a result, you have this back and forth, a lot of wasted time, got a lot of data quality errors in the data multiple times. And so ultimately, we really want to take that body of knowledge and put the technology where that body of knowledge lives. The data mesh is an attempt to do that.
17:49 Speaker 03 One part of what the data mesh folks are talking about is how to organize and how to structure a team to manage data across a large enterprise with very disparate and important data sources. That's very, very important. And there's some good ideas in data mesh for that. Architecturally, data mesh has this sort of odd idea that data is basically streaming, and you can use facilities like Kafka to do transforms as the data is in flight. And I don't believe that. I think that that is totally missing the fact that while there is streaming data, and you can do quite a bit with data that's simply streaming, in other words, append-only data. To me, another critical source of data is transactional data coming out of business systems.
18:33 Speaker 03 The streaming-based solutions have no answer for that, and they just sort of pretend that data consistency is unimportant. And I don't understand that because I put data consistency at the top of the issues that I think about when I think about managing data.
18:46 Martin Casado? Mesh has historically been one of these terms that conflates architecture with administrative domains, and it is in service mesh, and it is in Wi-Fi meshes and mesh networking, et cetera. I think Bob is exactly right, which is there is a very real issue with separate administration domains, separate processing domains, separate access to toolsets. That's very, very different than building a fully distributed architecture, which just tends to be hard and inefficient. And it's often not the people that promote the mesh idea, but when people hear the term "mesh," they default to full distribution, which tends to be just a bad way to build systems.
19:16 Speaker 01 Said like a networking guy.
19:17 Martin Casado? Having seen this exact same thing happen in other domains for a couple of decades.
19:23 Speaker 05 I think all of us are very technology-focused human beings, and so when we think about data mesh, we tend to think about the architecture part of it. Bob, I'm glad you pointed out the distributed teams and the people aspect to this. I think my constant question for the data mesh is, why can't you enable the distributed nature of what you're talking about with a unified architecture?
19:44 Speaker 04 My preference is always to have one data set that is very clean and well-understood, that we do not have to move anywhere, that is performance alongside our large batch analytical processing, which is also working with our data science. That's the nirvana. That's the goal, is to just have one data storage and then having something that sits over top of it, and each of those different things are specialized for each of the different use cases, but you have one data storage.
20:08 Speaker 01 I feel like the modern data stack keeps swallowing up more and more use cases. It killed cubes a while ago. It's mostly killed Hadoop at this point. It keeps pulling more use cases into its orbit because it's fundamentally so flexible and so capable of doing
20:27 Speaker 01 Many different things, well, enough that you don't really want to buy another system, build another system for that one use case. What do you think are some of the most interesting, surprising, significant use cases that may start to get pulled into the orbit of the modern data stack in the next couple of years?
20:45 Speaker 03 Complex data. We now have all this very, very interesting stuff that's happening in predictive analytics. And to me, we've gone from semi-structured data as being the most interesting data sources to now having a wide variety of data sources. I was talking to a company involved in the medical field yesterday, and just the rich amount of data that exists in the images and the doctor's notes, and all of that is opaque to our systems today. It will not be in five years. That will all become part of the modern data stack. And to me, that's a gigantic transformation into the types of applications that will be created in the years to come.
21:20 Speaker 05 My last job was I ran marketing for a company and I really went deep into growth marketing. The problem that you run into there is that you're constantly writing code to push data back and forth between systems because the different operational systems do different things and you need the same data in all of them. But no one has yet re-architected the systems who, in the modern data stack, just take all of the work that you've ingested and now push it back out to your operating systems, your operational systems. But I think we're at the beginning of that.
21:52 Speaker 03 What you're really talking about, Tristan, is the advent of the modern data app, which basically is an operational application that autonomously can make decisions for the business. And we've seen very few of those, I mean, very trivial examples of, boy, will they be significant in the future.
22:07 Speaker 01 There's really two visions of the data app that I've seen. And one of them is the data app is a separate system and you take the important data from your data warehouse and you push it. And then the other vision is the data app is just natively built to run on top of the data warehouse. I'm curious whether people have opinions about those two models and where they see that going.
22:28 Speaker 03 It's really the same conversation we've been having about how these things are built. A data app is predictive analytics that actually takes autonomous action. It takes the data that would otherwise be presented to a person and instead leverages that to actually take actions within the business. They're being built every which way today because there are a few good tools to build data apps. That will not be true in a few years.
22:49 Speaker 01 One of the things that you run into when you try to build data applications and take action automatically is that latency becomes incredibly important. Everybody in the ecosystem is battling this right now. I think there's a lot of different visions of how we're going to crush the latency problem and how low we need it to get. How low does latency need to be? At what point do we have most of the interesting use cases?
23:11 Speaker 03 People have dozens to hundreds or even thousands of operational systems. More and more, there are SaaS applications. They're outside of your organization. And they're always a source of truth now. They're the present. And a data warehouse or a data lake is about historical or the past. And what does that latency need to be? Does it need to be zero seconds? I don't think so. I mean, there are applications where zero seconds or instant is required, mostly having to do with eventing and alerting of some sort. Most of the time, if you can get it in a minute or two, you can leverage that data inside your historical system with predictive analytics to begin to perform actions on it.
23:49 Martin Casado? This is a very complicated topic that I think is very use case specific, but there tends to be serious trade-offs that systems designers make between latency and throughput. If you want higher throughput, you batch. And the reason that you batch is that you don't have as many domain crossings. However, if you look at most systems, you can make the trade-off, meaning you could do low latency in a data lake and you could do high throughput in a data warehouse or vice versa. These are not architectural limitations. They just tend to be the trade-offs that were made as a result of serving whatever the primary use case is. I've heard a number of these kind of latency throughput trade-off discussions, and you actually get down to machine level. They are just a result of the trade-offs that were made on the system going into it.
24:33 Speaker 01 One of the interesting things that we see is that the point at which you start to have to spend a lot more to get the latency lower is actually lower than people think. I suspect you can get down into the 10-second range with still the throughput-optimized architecture. Basically, the throughput-optimized architecture, I suspect, will go lower than we expect.
24:51 Speaker 04 What do you imagine will happen with the server layer? So your website still needs to operate over that data. Are you imagining that there's just going to continue to be a caching layer? Or is that going to be a separate system?
25:02 Speaker 03 It depends on what the characteristics of the system need to be. If something needs to be really low latency, today's data warehouses are not always the right solution for it. And so it just depends on the application. Latencies will go down in these products, but to Martine's point, some of the architectural choices make the latency characteristics of a Snowflake somewhat different than, for example, the latency characteristics of a MemSQL.
25:24 Speaker 05 One of the things that I would like to see more of in the future is Lambda architectures, but without the shelf tools. So my data flowing into a more streaming-like system and a more batch-like system so that I can get the best of both worlds. You're making trade-offs when you build these systems. As a user, I want to be able to choose and have both of them.
25:43 Speaker 01 All right, well, we have one minute left. I'd like to ask a yes or no question for everyone. Will there emerge another major data platform alongside Snowflake, Databricks, Google, AWS, and Azure? We'll start with you, Michelle. Yes or no?
26:01 Speaker 04 Yes.
26:02 Speaker 01 Bob?
26:03 Speaker 03 What's your time scale?
26:04 Speaker 01 Oh, yeah, sorry. In the next five years.
26:06 Speaker 03 Yes.
26:07 Speaker 04 Yes.
26:08 Speaker 03 But you know what may be relatively small relative to those guys?
26:10 Speaker 01 Well, I said major. That sounds like a...
26:12 Speaker 03 Look, it's... Snowflake was small five years ago.
26:14 Speaker 01 Tristan? I think no. Martine?
26:17 Martin Casado? Yes.
26:18 Speaker 01 All right. Thank you very much, everyone, for joining. This has been a really fun conversation. Really appreciate all of you being here. I know our audience does as well.
Previous How to Moderate Talks, Panels, Meetings, More (Virtual and Beyond!) Next The Social Serendipity of Cloud Gaming Page updated September 30, 2026 · transcript and summary are machine-generated
