What Happens When You Upgrade Code While the Old Version Is Still Running?
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:
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:
Version 1
└── PROCESS_QUERY() — V1 logic
Version 2
└── PROCESS_QUERY() — V2 logicOld 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.
VERSIONED SCHEMA
procedures
functions
views
release-specific logicAnd:
REGULAR SCHEMA
tables
configuration
query history
user settings
other objects that must survive upgradesThe 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