Skip to main content
The Hosted Database is delivered directly into your Snowflake account, so a change we make to the schema or to the data lands in your environment and can affect pipelines you have built on top of it. This article explains how we classify changes, how much notice you get for each class, and where those notices are published. This article is for the engineering and analytics teams who build on the Hosted Database. If you are looking for what actually shipped, see the Release Notes. If you would rather query a change before its release date than wait for it, see Early Release.

​
How changes are classified

Every Hosted Database change is classified into one of three categories before it ships. The category determines how much advance notice you receive.

​
Breaking changes

A change is breaking when it removes something you may be selecting, changes the type of something you are selecting, or changes what a value means. Specifically:
  • Removing a table or a column
  • Renaming a table or a column
  • Changing a column’s data type
  • Changing the semantic meaning of an existing column, including a column that begins returning null where it previously carried a value
  • Changing a table’s primary key

​
Behavior changes

A behavior change leaves the schema untouched. Every table and column keeps its name, type, and meaning, so nothing you have written stops working, but the amount of data behind it shifts enough that a query you already run would return a noticeably different answer. Behavior changes get 7 calendar days of notice and an impact analysis naming the tables affected and the approximate change in row count. Examples:
  • A table’s row count changes substantially, in either direction
  • The span of history a table carries changes substantially

​
Non-breaking changes

Additive changes are announced in the release notes when they ship, with no advance notice period:
  • Adding a new table
  • Adding a new column to an existing table
  • Adding documentation, column descriptions, or entity relationship diagram detail
We ship these frequently and intend to keep doing so. If your pipeline selects specific columns rather than select *, and does not assume a fixed column count or column order, additive changes are transparent to you.

​
Emergency changes

We reserve the right to ship a change without the notice period when a delay would cause greater harm than the change itself. In practice this is limited to:
  • A security or privacy issue, including data exposed to the wrong party
  • A data integrity problem severe enough that the data cannot responsibly be left in place
  • A change required by an upstream vendor or by regulation on a fixed deadline
When this happens we publish the release note at the same time as the change and state plainly that the notice period was not met and why.

​
Where notices are published

Advance notices and release notes both go to the Hosted Database Release Notes page. An advance notice appears as its own entry ahead of the change, naming the category and the tables affected, and the release itself gets a second entry when it ships. To have entries reach you automatically, see Subscribe to release feeds.

​
Building an integration that tolerates change

A few conventions on your side make almost all of our changes invisible to you:
  • Select named columns, not select *. A new column added to a table should not change the shape of your result set.
  • Do not depend on column order or column count. Both can change when a table gains columns.
  • Join on documented foreign keys. The entity relationship diagram at dbdocs.io/hosteddb_support/hosted_database_snowflake shows the supported relationships.

​
Frequently Asked Questions

​
Can I stay on the previous schema while I migrate?

No. The Hosted Database is shared live into your account, so there is a single current schema. The notice periods described above exist to give you a migration window without needing a parallel version. What you can do is work ahead of the change rather than behind it. Early Release is an optional channel that delivers a copy of the affected tables with a pending change already applied, so you can test your migration, or start using a new table, before the general availability date.

​
Can I get a change earlier than its GA date?

Yes, in many cases. Once a change is built and verified, Elation can copy the affected tables into the Early Release channel while the change waits out its notice period. Request access through the Support Portal.

​
Where do I raise a concern about an announced change?

Contact the Elation Support Portal with the subject line HDB - Change notice, and reference the date of the notice. If a change we have classified as a behavior change or as non-breaking would in fact break your integration, tell us during the notice window so we can partner on a solution. Depending on what the change touches, that might mean reworking how we deliver it, extending the notice period, or giving you the change in Early Release so you can adapt against it first.
If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>