> ## Content Index
> Fetch the complete content index at: https://www.techtaco.info/llms.txt
> Use this file to discover other available public pages before exploring further.

# What Happens When You Upgrade Code While the Old Version Is Still Running?
- URL: https://www.techtaco.info/what-happens-when-you-upgrade-code-while-the-old-version-is-still-running/
- Published: 2026-09-29T20:25:14.000Z
- Updated: 2026-09-29T20:25:14.000Z
- Author: Arif Khan

*The versioning problem we ran into while porting Zinzu to a containerized Native App*

What happens when you deploy new code while the old code is still running?

In a simple application, you may not think much about it. You deploy Version 2, replace Version 1, and move on.

Long-running systems are different.

A job may start under V1 and still be running when V2 is deployed.

The old job expects V1 behavior.

New work expects V2 behavior.

So which version of the code should each one use?

We ran into this while spending a few late nights porting Zinzu to Snowflake as a containerized Native App.

Zinzu has containers, Snowflake procedures and functions, long-running analysis jobs, ai and data in tables and configuration that must survive upgrades.

That is where Snowflake's **versioned schemas** started to make sense.

Our first reaction was simple:

> The app is already versioned. Why do we need another layer of versioning?

The answer is that they solve different problems.

**Application version:** Which release is this?

**Versioned schema:** Which version of the procedures, functions, views, and other code belongs to that release?

## The problem

Imagine V1 has this procedure:

```sql
PROCESS_QUERY()
```

A long-running job starts under V1 and uses that procedure.

A few minutes later, V2 is installed with a changed version of `PROCESS_QUERY()`.

If there were only one copy of that procedure and V2 simply replaced it, the job that started under V1 could now find itself depending on code that has changed underneath it.

That is exactly what we want to avoid.

Conceptually, we want this:

```text
Version 1
  └── PROCESS_QUERY() — V1 logic

Version 2
  └── PROCESS_QUERY() — V2 logic
```

Old work finishes with V1 logic.

New work uses V2 logic.

That is where versioned schemas come in.

## What actually gets pinned?

This part can sound more complicated than it is.

When a query or job starts under V1, Snowflake keeps that running work tied to V1.

If V2 is installed while the V1 work is still running, the running work does not suddenly switch to V2 logic halfway through.

It finishes as V1 work.

New work started under V2 uses V2.

Snowflake calls this **version pinning**.

The versioned schema is what allows Snowflake to keep the V1 procedures, functions, views, and other release-specific code available while V1 work is still using them.

That was the part that made the whole thing click for us.

## Code and stored data are different

There is another important part.

Code can change with every release.

But data in tables, configuration, query history, user settings, and other stored information should not disappear just because a new version is installed.

So the split is pretty simple.

```text
VERSIONED SCHEMA

procedures
functions
views
release-specific logic
```

And:

```text
REGULAR SCHEMA

tables
configuration
query history
user settings
other objects that must survive upgrades
```

The first group can change from release to release.

The second group needs to stay.

## What about containers?

For a containerized application, the containers themselves have their own upgrade lifecycle.

But that does not remove the problem.

The Snowflake-side code around those containers still needs to handle old work and new work existing at the same time.

So containers add another moving part, but the basic idea stays the same.

## The easiest way we remember it

**Application version = the release**

**Versioned schema = the code that belongs to that release**

**Regular schema = the data, configuration, and other objects that must survive every release**

Once we stopped thinking of app versions and versioned schemas as two ways of versioning the same thing, the design became much easier to understand.

They solve different problems.

One tells the system **which release is running**.

The other helps make sure **the right code stays with that release while work is still running**.

And the data that needs to survive remains outside that release-specific code.

### We’re actively working on bringing **Zinzu to Snowflake and Databricks**, and both are coming soon.

visit https://zinzu.io