Native App vs Full Platform: Your Complete Guide to Choosing the Right Anavsan Solution

Anavsan ships two ways to look at Snowflake spend, and they are easy to confuse because they share a name. One is a Snowflake Native App you install from Marketplace. It stays inside the account, reads metadata only, and shows credit, warehouse, query, and storage consumption without an external integration project. The other is the full Anavsan platform, powered by APEX: Trace, Assign, Prove, and Enforce. That product is not a thicker dashboard. It is the operating loop that turns an expensive workload into owned, simulated, and closed work.

Teams usually ask which one is “right” as if the answer were a feature matrix. The more useful question is what is blocking you this quarter. If security will not approve data leaving Snowflake, or procurement will not open a new vendor review, you need visibility that installs where engineers already work. If you already know which warehouses are expensive and the bill still does not move, you need ownership, simulation, and proof—not another chart of the same ACCOUNT_USAGE rows.

This guide is the decision framework. It explains what the Native App actually does, where monitoring stops being enough, what the full platform adds, and how to choose without treating one as a consolation prize for the other.

Two products, two jobs

Both products are Anavsan. The Native App is not a crippled demo of APEX, and the full platform is not “the same screens with more charts.” They solve different jobs in the same cost problem.

The Native App is a Snowflake-native monitoring surface. You find it on Marketplace, grant metadata privileges, and start seeing consumption inside the account. It inherits Snowflake RBAC. It does not export business data. Typical install is under ten minutes. That is the point: visibility that security and procurement can actually approve this week, not a six-month integration.

The full platform is the accountability loop. Detection is an input. The product is what happens after the alert: which workload spent the credits, who owns the fix, whether a change is safe before production, and whether credits actually fell after it shipped. That loop is documented on How Anavsan Works. Monitoring tells you the warehouse is expensive. Governance tells you which query, which owner, and whether the cheaper runtime lasted.

What the Native App actually monitors

The app reads Snowflake metadata—ACCOUNT_USAGE and INFORMATION_SCHEMA—not tables that hold customer or operational records. From that metadata it surfaces the signals most teams otherwise assemble by hand: credit consumption by warehouse and service, warehouse utilization, idle time, queuing and concurrency, query cost signals, and storage growth including Time Travel and Fail-safe. Advisory recommendations sit on top of those signals. They are informational. The Native App does not rewrite queries or change warehouse configuration for you.

That constraint is a feature for a large class of buyers. External monitoring tools often stall on the same sentence: the security team will not approve exporting Snowflake metadata outside the environment. A Marketplace app that never leaves the account removes that sentence. Engineers stay in Snowflake. There is no separate auth system to review, no agent to deploy, and no production query load beyond what Snowflake already records.

Install is the listing on Snowflake Marketplace, Anavsan Snowflake Credit and Performance Monitoring. Grant the app’s required roles, refresh, and you have credit visibility on a single account. Monitoring for one Snowflake account is free. That is enough to answer “which warehouses are consuming credits” and “is storage growth out of line” without standing up the full governance workflow. For a shorter product walkthrough, see the Native App launch post.

Where monitoring stops being cost control

A dashboard of top warehouses is not the same as a cheaper bill. Native telemetry can show that an X-Large sat idle, that a query spilled, or that Time Travel retention is holding dropped tables. It does not assign the warehouse to an owner. It does not simulate a right-size or a rewrite before someone changes production. It does not prove that last month’s “optimization” reduced credits, or keep the same pattern from returning after the engineer who fixed it moved teams.

That is why cost programs stall after the first good month of visibility. The team can name the expensive objects. The work still sits in Slack, a spreadsheet, or a ticket with no owner. Resource monitors and Query History have the same ceiling: they detect. They do not close. If the current pain is “we cannot see,” the Native App is the right first product. If the current pain is “we can see, and nothing gets fixed,” more monitoring will not move the number.

The gap shows up in operations, not in charts. An alert fires. Nobody is clearly accountable. A proposed warehouse change is too risky to try on the shared BI cluster. Finance asks for savings proof and gets a screenshot. Next month the same query is back. Visibility did its job. The operating model did not.

What the full platform adds

APEX is built for the work after detection. Trace maps credits to the workload and the engineer using Snowflake signals and a Private Knowledge Graph. Assign routes the issue with context, priority, and an owner. Prove simulates query and warehouse changes before they hit production, then validates whether credits fell after the change. Enforce drives the item to documented closure instead of leaving it as an open alert. That is the difference between a monitoring product and a workload governance platform.

The full platform is also where multi-account, collaboration, and policy live. Native App monitoring is the in-account view. APEX is the system of record for expensive recurring queries, ownership, simulation results, and savings evidence—across accounts when the organization is larger than one Snowflake login. Signup is at agent.anavsan.com/signup. Paid paths are Accountability and Enforcement on the pricing page; a 14-day trial covers those plans.

None of that replaces Snowflake’s own monitors. It sits on top of the same metadata the Native App reads, then adds the workflow Snowflake does not ship: owner routing, pre-production simulation, and closure with proof. If you already have Query History and still cannot get a rewrite into production, the missing layer is not another credit chart.

How to choose

Start with the Native App when the first constraint is access. Security wants metadata-only, in-account monitoring. Procurement will not open a long vendor review. You have one Snowflake account and you need a business case before anyone will fund optimization work. You want to see credit, warehouse, query, and storage patterns this week, not after a project plan. Marketplace install is the shortest path to that evidence.

Move to the full platform when visibility is no longer the bottleneck. Alerts already exist and stall. Engineers will not change a production query without knowing the credit and runtime impact. FinOps needs a record that savings happened, not a slide that says they should. You run more than one account. You need the expensive workload to have an owner, a simulated fix, and a closed result. That is APEX, not a second monitoring install.

A practical test: if a new dashboard would change what you do on Monday, you are still in the Native App job. If you already know Monday’s expensive jobs and cannot get them assigned, simulated, and proven, you are in the full-platform job. Do not wait for a perfect catalog comparison. The constraint in front of you is the product.

You can use both

This is not a migration tax. Some teams keep the Native App as the Snowflake-native monitoring surface that security already approved, and run APEX as the execution layer that turns those findings into assigned work. Others start on Marketplace, build the internal case from in-account evidence, then add the platform when the bill still does not move. You do not have to uninstall one to use the other.

There is no required middle product. If you only want monitoring, stay there. Monitoring for one account remains free. If you already know you need ownership and simulation, skip the detour and start the full-platform trial. The mistake is treating the Native App as incomplete APEX, or treating APEX as a requirement before you are allowed to see your own credits.

Start with the constraint, not the catalog

Choose the Native App when you need Snowflake credit visibility that never leaves the account. Choose the full platform when you need those credits traced to a workload, assigned to an owner, simulated before production, and closed with proof. They are two products for two jobs in the same spend problem.

If you are still deciding which job you are in, take the Snowflake Cost Accountability Gap Assessment. It is a faster signal than another feature table. Install the Native App from Marketplace when the gap is visibility. Start the full platform when the gap is everything that happens after the alert.