In the fast-moving world of data, the Snowflake AI Data Cloud has established itself as an essential part of the Modern Data Stack. Through its versatile platform, organizations can build efficient data warehouses and harness the power of data monetization via Secure Data Shares, accessible through the Snowflake Marketplace. Beyond data sharing, Snowflake takes a step further by offering native hosting for SaaS applications using its innovative Native Application Framework.
This blog will shed light on when companies should build Native Apps in Snowflake and when it might not be the best option, providing you with the confidence to make informed decisions for your data strategy.
Understanding Native Apps in Snowflake
The Snowflake Native Application Framework adheres to the same RBAC principles and encryption standards governing natively hosting data. It also provides features like Streamlit for UI and Dashboards, native integration with Snowflake’s AI layer (Cortex), file-based development, and automated versioning and release management.
You can deploy your existing applications as-is in Snowpark Container Services or build new applications using the Native App Framework project components.
Developers can benefit from a file-based development approach to implement business logic in Python, Snowpark, SQL, JavaScript, etc. The applications can be shared with internal or external customers via the Marketplace or private sharing. Snowflake manages the distribution and deployment of the product so that developers can focus on building new features faster.
Customers can install applications in their own Snowflake accounts and use them with their data, eliminating the need to extract data for external processing. At the same time, Snowflake protects the application owner’s Intellectual Property by preventing code sharing with customers.
But how can you, as a business leader, product owner, architect, or engineer, identify whether you should build or convert your product into a Snowflake Native App? This is not a straightforward decision, but one that can be simplified using a systematic approach.
Should I Build a Native App on Snowflake?
You should consider the following questions when deciding to build a Native App. Based on your answers, you can identify if your use case can be easily implemented (Green Light), if you should proceed with caution (Yellow Light), or decide not to build at all (Red Light).
Question | Green | Yellow | Red |
|---|---|---|---|
Do the potential users of my application use Snowflake? | Yes | Yes | No |
Does my application need to interact with other Native Apps? | No | Yes | Yes (other apps are external) |
Can all features be converted into procedures / UDFs? | All | Some | None |
My customers span across multiple Cloud Platforms | No | Yes (AWS and Azure) | Yes (AWS, Azure, and GCP) |
Does the application need load balancing, failure recovery, or replication? | No | No | Yes |
Does my application need to expose APIs to non-Snowflake endpoints? | No | Yes | Yes |
Does my application need support for private connectivity, VPS, or Government regions? | No | No | Yes |
Also, here is a flowchart to expedite the decision-making –
Green Light Scenarios – When to Build Native Apps in Snowflake
If your answers to the questionnaire match the grid below, you can consider your use case a Green Light scenario. This section will also include some examples of Green Light scenarios.
Question | Green |
|---|---|
Do the potential users of my application have active Snowflake accounts? | Yes |
Does my application need to interact with other Native Apps? | No |
Can all features be converted into procedures / UDFs? | All |
My customers span across multiple Cloud Platforms | No |
Does the application need load balancing, failure recovery, or replication? | No |
Does my application need to expose APIs to non-Snowflake endpoints? | No |
Does my application need support for private connectivity, VPS, or Government regions? | No |
Examples:
Enable In-house Data Processing
This is perhaps the most valuable use case for Native Apps. Organizations across industries view data security as critical. Every second, they generate vast amounts of data and implement stringent security and governance standards using RBAC principles in Snowflake and other tools within the Snowflake ecosystem.
Often, raw data needs to be exported and sent to vendors who own the IP to analyze and augment that data, providing meaningful results. With the Native App Framework, these applications can be converted into Snowflake-hosted SaaS applications, allowing them to run inside customers’ own Snowflake accounts. This completely mitigates the risk of exporting data outside of an organization’s security framework.
Vendors can also rely on features like Billing Events and event sharing to monetize app usage, provide support, and troubleshoot the apps. Customers can feel confident about the applications, as listings undergo automated security scans and offer clear visibility and control over the information shared with providers.
Provide Streamlit-Powered UI to Manage Data Lifecycles OR Dashboards
The Native App Framework supports UI development using Streamlit, which can be valuable for data processing applications requiring human intervention for approvals or specific processes. Streamlit-powered UIs can be bundled with the native application for such use cases.
Providers can also utilize Streamlit to create simple dashboards for quick analysis of output tables or tables accessible to the native app. Snowflake integrates with industry-standard Business Intelligence tools like Sigma for more powerful dashboards. Still, native applications can meet the needs of simpler use cases where out-of-the-box dashboards suffice for meaningful analysis.
Share Data to Augment Business Logic
Providers can also share data with consumers in the native application package. The provider can manage this dataset completely, and consumers can view data from this dataset as required. The applications installed on the consumer side can use this shared data internally to run business logic, augment results, etc.
--Create Package
CREATE APPLICATION PACKAGE app_package;
--Grant privileges on schema / table / view to be shared
GRANT USAGE ON SCHEMA app_package.shared_schema
TO SHARE IN APPLICATION PACKAGE app_package;
GRANT SELECT ON TABLE app_package.shared_schema.shared_table
TO SHARE IN APPLICATION PACKAGE app_package;
--Grant privileges on objects outside the application package and create view
GRANT REFERENCE_USAGE ON DATABASE other_db
TO SHARE IN APPLICATION PACKAGE app_pkg;
CREATE VIEW app_pkg.shared_schema.shared_view
AS SELECT c1, c2, c3, c4
FROM other_db.other_schema.other_table;
--Grant privileges on schema and view to the application
GRANT USAGE ON SCHEMA app_pkg.shared_schema
TO SHARE IN APPLICATION PACKAGE app_pkg;
GRANT SELECT ON VIEW app_pkg.shared_schema.shared_view
TO SHARE IN APPLICATION PACKAGE app_pkg;
Build Dashboards for Account-Level Metrics and Optimizations
Organizations with decentralized IT teams often manage multiple Snowflake accounts, making it beneficial for them to develop a Native App for internal distribution. This app can streamline operations by disseminating best practices, offering visualizations on Snowflake usage and costs, and automating resource provisioning, among other functionalities.
A good example of such an application is the Advisor Tool from the phData Toolkit. The Advisor Tool provides detailed reports and visualizations for metrics on Snowflake performance, security, usage, etc. This tool is available as a Native App via the Snowflake Marketplace.
Applications can request access to the SNOWFLAKE database using the IMPORTED PRIVILEGES privilege request in the manifest file to fetch usage and cost-related data from appropriate views.
Yellow Light Scenarios – Proceed with Caution
If your questionnaire responses align with the grid below, your use case can be categorized as a Yellow Light scenario. This section will explore examples of Yellow Light scenarios.
|
Question |
Yellow |
|---|---|
|
Do the potential users of my application use Snowflake? |
Yes |
|
Does my application need to interact with other Native Apps? |
Yes |
|
Can all features be converted into Snowflake native objects? |
Some |
|
My customers span across multiple Cloud Platforms |
Yes (AWS and Azure) |
|
Does the application need load balancing, failure recovery, or replication? |
No |
|
Does my application need to expose APIs to non-Snowflake endpoints? |
Yes |
|
Does my application need support for private connectivity, VPS, or Government regions? |
No |
Examples
Integrate Multiple Native Applications
In the world of SaaS applications, it is common to run into the requirement of integration with other applications for various purposes. Common architectural solutions for such requirements include message queues, pub-sub architecture, service bus architecture, API integration, etc. In the world of Snowflake Native Apps, such functionality can be implemented using database objects, but with some caveats:
Native App instances exist as database-level objects. By default, all objects like tables, views, procs, and UDFs are created inside the application boundary; other applications do not have access to these objects. However, the application role with access to those objects can be granted to other applications to establish a functionality similar to API integration. An application owner role (the Account role used to install the two applications to be integrated) is needed to execute the grant. The example of the Grant statement is:
GRANT APPLICATION ROLE hello_snowflake_app.executor_role TO APPLICATION integrator_app;
A service bus type architecture can also be established by creating a database outside any application boundaries, and granting appropriate
DB/SCHEMA/TABLElevel privileges to the applications that need to interact with the service bus. This can be achieved by either providing detailed steps to the consumers to create the database and execute grants, or by making any one of the integrating apps the owner of the common database. By doing so, one app can manage the database and its objects throughout its existence. Upgrading the objects in the common/shared database is also managed through the upgrades to the owner application.
Not all Features can be Converted into Snowflake Native Components
Suppose there are dependencies in your application that cannot be converted into Snowflake native components (like 3rd party executables, libraries, etc.). In that case, consider using Snowpark Container Services to host such applications in Snowflake. This service enables users to run containerized workloads directly within Snowflake, ensuring that data doesn’t need to be moved out of the Snowflake environment for processing.
Using this service unlocks several possibilities like:
Create long-running services.
Use GPUs to boost the speed and processing capabilities of a system.
Write your application code in any language (for example, C++).
Use any libraries with your application.
This use case is placed in the Yellow category due to limitations such as its lack of availability in certain cloud platforms or regions (all regions of GCP and government regions in AWS / Azure) and the higher degree of engineering effort needed to develop and maintain the applications in Snowflake.
Expose APIs for Applications over the Public Internet
Containerized applications running in Snowpark Container Service can expose APIs over the public Internet. They can take advantage of the long-running services feature and the ability to provide external access integrations to host APIs or consume external APIs. Providers can enable network rules within Snowflake and configure long-running services, which Snowflake completely manages.
Applications need latest Streamlit Features
The framework currently supports Streamlit v1.35. Here’s a detailed list of unsupported Streamlit features. If it is absolutely necessary to use any versions higher than v1.35, then a workaround can be to containerize the Streamlit application and deploy with Snowpark Container Services.
Red Light Scenarios – When Not to Build Native Apps in Snowflake
If your answers to the questionnaire match the grid below, consider your use case a Red Light scenario. Being aware of the limitations of the Native App Framework is essential in deciding whether a Native App should be built.
| Question | Red |
|---|---|
Do the potential users of my application have active Snowflake accounts? | No |
Does my application need to interact with other Native Apps? | Yes (other apps are external, not exposing APIs) |
Can all features be converted into procedures/UDFs? | None |
My customers span across multiple Cloud Platforms | Yes (AWS, Azure, and GCP) |
Does the application need load balancing, failure recovery, or replication? | Yes |
Does my application need to expose APIs to non-Snowflake endpoints? | Yes |
Does my application need support for private connectivity, VPS, or Government regions? | Yes |
Snowflake provides a detailed list of the framework’s limitations, but here are a few examples of use cases that may be considered showstoppers.
Examples
Need for Failover or Business Continuity
Snowflake currently does not offer failover or business continuity support for Native Apps. Industries such as Banking, Financial Services, and Retail, which rely on business-critical applications, require such failover support. As of the time this blog was written, Snowflake does not cater to these needs. Consequently, if failover support is essential, explore alternative solutions offered by cloud platform services like AWS, Azure, or GCP.
Cloud Platform/Region Support
Snowflake provides cross-cloud auto fulfillment, allowing Native App providers to list their applications in multiple clouds/regions. However, if your Native Apps use Snowpark Container Services, this service is currently not supported for GCP. So, if your target consumers have Snowflake accounts in GCP, they cannot access the listing unless you create a separate provider account in GCP and create a new listing. This can be done by designing the CI/CD pipelines to target multiple provider accounts, but if that is not possible, such use cases should be avoided.
Applications Need Temporary Tables/Stages
There can be use cases where applications need to store and use intermediate results in the form of temporary tables, or write files in temporary stages, without persisting the data. These features are currently not supported by the framework and should be avoided.
Cost Considerations for Native Apps in Snowflake
Building and distributing Native Apps require cost considerations from providers and consumers.
For Providers
There is a cost associated with engineering (development and quality assurance), and distributing the applications across multiple cloud platforms, availability zones, and regions. Snowflake provides ways to monitor and optimize costs, like data sharing usage views, and cost optimization tools like Egress Cost Optimizer.
Providers can monetize application usage by defining Billing Events. They can specify custom billing events using the SYSTEM$CREATE_BILLING_EVENT system function or define usage-based pricing plans. The listings can be configured to enable the billing events as defined in the application. This provides transparency to consumers on how they are billed for application usage.
Following views in SNOWFLAKE.DATA_SHARING_USAGE schema are designed to help the providers manage costs and application usage metrics.
View | Description |
|---|---|
| This view in the |
| This view in the |
| This view details how much data is stored in specific regions, and which listings and databases the data storage is associated with. |
| This view details how much data is refreshed to specific regions, and which listings and databases the data refreshes are associated with. |
| The view returns a record for each consumer account that queried data for a given date. |
| The |
| The |
| This view includes the history for a specific listing. It is only visible to providers of paid listings and includes the history of payment statuses per invoice for purchased listings. |
| Only visible to providers of paid listings, this view includes the history of payment statuses per invoice for purchased listings. |
| This view includes the history of consumer payments for a specific listing. |
| The view includes the history of consumer queries for a specific listing. |
| This view is updated when consumers change their pricing plan, start or end a trial listing, or cancel a subscription. |
For Consumers
Consumers of Native Apps need to be aware of costs in the following areas:
Credit Consumption by Applications Running in their Accounts
Applications will use warehouses and Compute Pools in consumer accounts to execute their functionality. Also, any data generated by the application will stay within their accounts. The credit consumption can be tracked using Warehouse usage and Compute Pool usage. For warehouses, views in SNOWFLAKE.ACCOUNT_USAGE schema, like WAREHOUSE_METERING_HISTORY, QUERY_HISTORY, etc., are useful.
For Compute Pools, the application logs recorded in the Event table can provide information about start and end times, number of nodes, etc.
Custom Budgets
Budgets allow you to define a monthly spending limit on the compute costs for an app. When you add an app to a custom budget, the objects owned by the app and that consume credits are automatically added to the custom budget. These include the warehouses and compute pools that are owned by the app.
Skill Set and Resources for Native Apps
The Native App Framework relies on the same Software Engineering principles that make SaaS applications successful across various industries. Here is a list of some of the standard and specialized skills that we require our experts at phData to have in order to build successful Native Apps for our clients:
Snowflake Role-Based Access Control principles
Snowflake Scripting / SQL
Snowpark / Python / Javascript
UDF/UDTF Concepts
Streams and Tasks
Version Control systems like Git / Bitbucket, etc.
Resources needed to start building native apps:
Snowflake-CLI
IDE of your choice (like VSCode)
Provider Snowflake Account
Separate Account(s) for testing as Consumer
Version Control (Github, Bitbucket etc.)
Customer Success Stories of Native Apps at phData
At phData, we take pride in driving innovation and delivering tangible results for our clients. One such success story comes from our collaboration with a leading company in the Identity Management industry.
This client, tasked with handling large volumes of Personally Identifiable Information (PII), has long invested in robust infrastructure, dedicated personnel, and rigorous processes to safeguard incoming data, establish strong governance practices, and enforce stringent access control mechanisms.
With phData’s expertise, the client embarked on a transformative journey to convert their applications to Native Apps. This strategic move minimizes the need to handle third-party PII data, resulting in significant savings in infrastructure and resources and reducing legal risks associated with third-party data handling.
Additionally, this shift opens up opportunities to attract new customers who prefer not to share their sensitive data with external vendors, particularly those already utilizing Snowflake.
Our work didn’t stop there. phData has also been instrumental in implementing groundbreaking use-cases such as:
- Containerizing their current applications using Snowpark Container Services, ensuring enhanced flexibility and efficiency.
- Leveraging Streams and Tasks within native apps to seamlessly orchestrate workflows across other native apps, enhancing operational effectiveness.
- Formatting and encrypting outputs for secure publication to external APIs via native apps, ensuring compliance and data integrity.
Introducing the phData Toolkit
The phData Toolkit is a collection of high-quality data applications to help you migrate, validate, optimize, and secure your data. Various tools in the toolkit are optimized for Snowflake, and currently, the Advisor and Access Tools are available as native applications in Snowflake Marketplace.
phData Toolkit Native App | App Overview |
|---|---|
The Advisor tool comes with a pre-configured set of checks to identify opportunities and provide recommendations that ensure your Snowflake environment is following best practices and industry standards across a variety of categories. | |
The Access Tool is a first-of-its-kind application that helps users and administrators better understand roles and privileges in the Snowflake Data Cloud using a searchable interface where you can drill down into your Snowflake account metadata, including users, roles, privileges, databases, and schemas. |
Closing
The Snowflake Native App Framework is indeed a powerful platform for powering up your data-driven applications, but it is important to weigh factors like current limitations, the nature of use cases, and cost considerations.
With the right skills and resources, you can build successful data applications, and at phData, we are committed to using our Snowflake expertise to help you build and monetize applications.
Looking to enter the world of Native Apps?
Let phData be your guide.
FAQs
I am a Native App Consumer. Can phData help me manage Native Apps in my Snowflake account(s)?
Of course! phData has a depth of experience in Snowflake administration, migration, and implementation. We have an array of tools in our Toolkit to manage and automate RBAC implementation, resource provisioning, etc. Managing native applications, defining roles, managing resource monitors, budgets, etc., are activities that phData engineers have successfully done for multiple customers. We have been Snowflake Partners of the year for the last 5 years and are in a unique position to help both providers and consumers of Native Applications to effectively develop, distribute, and use applications to help your organizations be successful with Snowflake.
Does my use case fit any of the use cases described in this blog?
If your answer is yes or if you are unsure, please contact your phData Sales Representative to learn how we can collaborate with you on your journey to Native App success.
