Jun 18, 2022·edited Jun 19, 2022Liked by Benn Stancil
Oracle had much of the same thinking as far back as 20+ years ago (maybe more, but I wasn't around then...). So if we're on making comparison, I think the right comparison is that we're seeing the next iteration of Oracle's proprietary in-database products.
The question is how open will that implementation be? And will apps built for Snowflake work on GCP, AWS stacks? I suspect no. In the end, I am not sure this is as exciting as it sounds. I think we're just looking at a proliferation of in-database functionalities that are required for a mature enterprise database product. And the standard there for decades has been Oracle.
What we're actually probably going to see is a few iterations of implementations with relatively open standards. Something that will give Snowflake's competitors their own good ideas to make in-database app products. Then competition on in-database apps kicks off, and Snowflake will start making decisions. towards making App implementation much more proprietary, using custom languages totally incompatible with anything else.
I think the more interesting future is emergence of another Streamlit, but one like DBT that is able to raise >$300mil and build an an entire cloud platform around the idea of community contributed apps. That would be an interesting future.
Maybe what we really need is new “atomic unit” of data. Not tables. Not dashboards. Not even apps. Let’s call it an INS (for insight, insert, or inside joke). A true Data OS would make it easy for humans (or machines) produce, consume, and reuse INS without having worry about the complexity of formats, compute, or even platform.
Great thought piece. I'm with you on the utility of data apps, a vertical approach that delivers immediate business value versus a general horizontal BI tool that says "you can build anything you want, go for it."
One of my challenges in delivering data apps has been the fact that different customers have different data stacks, especially database preference. Perhaps this iSnowflake approach simplifies that, but does it then push them to a single vendor that data app creators sort of homogenize around?
Could an inverted approach that is database agnostic provide much of the same value? A lot of the data app utility is in the data transformation component - getting data from the disparate systems of all the potential data app customers to be used by a generic data app UI. For example, deliver a data app with dbt while paying special attention to keeping it database agnostic, then build your data app UI (Mode, custom app, Tableau, etc.) based on those models. Free, agnostic, open source.
For many, is there value in a $1500 phone that is roughly the same as a $500 phone? I know this is blasphemy, but how much of that $1500 is sales and marketing versus real value? Also, how do marketplace app creators feel about their end of the deal?
How to address these issues is a tough question. I really don’t understand/cannot see how to embed or to make the privacy/compliance team to work together.
How do you think that this topic would translate for compliance/security people within companies? I strongly believe that the hardest part is to connect who draw these kind of rules (lawyers, cfo, board member etc) with products such as snowflake and the IT.
COngrats and hope you've won some money betting on the roulette.
'Data app' is a weird term. Fundamentally, all apps are data apps. And if we can eventually write a CRM in Snowflake, that's not some special 'data' version of a CRM. It's just a CRM.
I gotta be honest: it feels like we are still in the VMS era of the Data OS, where the first-party services are very different than third-party apps. I don’t feel like I’ve seen any full-stack data platform that is designed for extensible abstraction the way UNIX was.
Maybe we have to wait half a decade for Snowflake and DataBricks to hack their way into pseudo-data-apps before someone can design the right building blocks to self-assemble into a coherent stack...
"...for Snowflake Summit, the first data Megaconference1 since 2019"? Sir. The second. The second data Megaconference since 2019. Tableau Conference was May 17-19! 🤓
> What if apps aren’t simple widgets for consumption, but are foundational programs that fundamentally change how Snowflake operates?
Um, sure. But “apps” is probably not the optimal term for that, or even the right layer to focus on. What you’re really talking about is a “Data OS” whose programs can be apps, daemons, scripts, extensions, etc. Right?
Oracle had much of the same thinking as far back as 20+ years ago (maybe more, but I wasn't around then...). So if we're on making comparison, I think the right comparison is that we're seeing the next iteration of Oracle's proprietary in-database products.
The question is how open will that implementation be? And will apps built for Snowflake work on GCP, AWS stacks? I suspect no. In the end, I am not sure this is as exciting as it sounds. I think we're just looking at a proliferation of in-database functionalities that are required for a mature enterprise database product. And the standard there for decades has been Oracle.
What we're actually probably going to see is a few iterations of implementations with relatively open standards. Something that will give Snowflake's competitors their own good ideas to make in-database app products. Then competition on in-database apps kicks off, and Snowflake will start making decisions. towards making App implementation much more proprietary, using custom languages totally incompatible with anything else.
I think the more interesting future is emergence of another Streamlit, but one like DBT that is able to raise >$300mil and build an an entire cloud platform around the idea of community contributed apps. That would be an interesting future.
Maybe what we really need is new “atomic unit” of data. Not tables. Not dashboards. Not even apps. Let’s call it an INS (for insight, insert, or inside joke). A true Data OS would make it easy for humans (or machines) produce, consume, and reuse INS without having worry about the complexity of formats, compute, or even platform.
Great thought piece. I'm with you on the utility of data apps, a vertical approach that delivers immediate business value versus a general horizontal BI tool that says "you can build anything you want, go for it."
One of my challenges in delivering data apps has been the fact that different customers have different data stacks, especially database preference. Perhaps this iSnowflake approach simplifies that, but does it then push them to a single vendor that data app creators sort of homogenize around?
Could an inverted approach that is database agnostic provide much of the same value? A lot of the data app utility is in the data transformation component - getting data from the disparate systems of all the potential data app customers to be used by a generic data app UI. For example, deliver a data app with dbt while paying special attention to keeping it database agnostic, then build your data app UI (Mode, custom app, Tableau, etc.) based on those models. Free, agnostic, open source.
For many, is there value in a $1500 phone that is roughly the same as a $500 phone? I know this is blasphemy, but how much of that $1500 is sales and marketing versus real value? Also, how do marketplace app creators feel about their end of the deal?
Interesting stuff, thanks!
I'm really so glad that someone else called out how squishy the carpet was. It was ... almost hard to walk on.
How to address these issues is a tough question. I really don’t understand/cannot see how to embed or to make the privacy/compliance team to work together.
Do you any good solution?
How do you think that this topic would translate for compliance/security people within companies? I strongly believe that the hardest part is to connect who draw these kind of rules (lawyers, cfo, board member etc) with products such as snowflake and the IT.
COngrats and hope you've won some money betting on the roulette.
'Data app' is a weird term. Fundamentally, all apps are data apps. And if we can eventually write a CRM in Snowflake, that's not some special 'data' version of a CRM. It's just a CRM.
I gotta be honest: it feels like we are still in the VMS era of the Data OS, where the first-party services are very different than third-party apps. I don’t feel like I’ve seen any full-stack data platform that is designed for extensible abstraction the way UNIX was.
Maybe we have to wait half a decade for Snowflake and DataBricks to hack their way into pseudo-data-apps before someone can design the right building blocks to self-assemble into a coherent stack...
"...for Snowflake Summit, the first data Megaconference1 since 2019"? Sir. The second. The second data Megaconference since 2019. Tableau Conference was May 17-19! 🤓
> What if apps aren’t simple widgets for consumption, but are foundational programs that fundamentally change how Snowflake operates?
Um, sure. But “apps” is probably not the optimal term for that, or even the right layer to focus on. What you’re really talking about is a “Data OS” whose programs can be apps, daemons, scripts, extensions, etc. Right?