Is Snowflake ‘open’ enough? | InfoWorld

The relative deserves of “open” have been hotly debated in our business for several years. There is a feeling in some quarters that being open is beneficial by default, but this view does not generally entirely take into consideration the goals being served. What matters most to the huge the greater part of companies are stability, effectiveness, expenses, simplicity, and innovation. Open must generally be used in support of these aims, not as the intention in by itself.

When we develop products and solutions at Snowflake, we evaluate where by open requirements, open formats, and open supply can build the finest result for our prospects. We imagine strongly in the constructive influence of open and we are grateful for the open supply community’s attempts, which have propelled the huge data revolution and a lot far more. But open is not the solution in each instance, and by sharing our contemplating on this matter we hope to give a practical point of view to some others generating innovative technologies.

[ Also on InfoWorld: What is future for the cloud data warehouse ]

Open is often recognized to describe two wide aspects: open requirements and open supply. We’ll appear at them every in far more detail listed here.

Open requirements

Open requirements encompass file formats, protocols, and programming models, which include things like languages and APIs. Whilst open requirements normally give benefit to consumers and suppliers alike, it is critical to recognize where by they provide increased-degree priorities and where by they do not.

File formats

We concur that open file formats are an critical counter to the very serious issue of seller lock-in. Wherever we vary is in the assertion that these open formats are the optimum way to stand for data during processing, and that immediate file access must be a key characteristic of a data system. 

At initially glance, the capability to directly access data files in a common, nicely-recognized format is captivating, but it becomes troublesome when the format demands to evolve. Think about an enhancement that allows greater compression or greater processing. How do we coordinate across all possible consumers and applications to recognize the new format?

Or take into consideration a new stability capacity where by data access relies upon on a broader context. How do we roll out a new privacy capacity that explanations via a broader semantic comprehending of the data to avoid re-identification of persons? Is it vital to coordinate all possible consumers and applications to undertake these improvements in lockstep? What transpires if one particular of these is skipped?

Our long knowledge with these trade-offs offers us a strong conviction about the superior benefit of offering abstraction and indirection as opposed to exposing uncooked data files and file formats. We strongly imagine in API-pushed access to data, in increased-degree constructs abstracting away bodily storage details. This is not about rejecting open it is about delivering greater benefit for prospects. We stability this with earning it very straightforward to get data in and out in common formats.

A good illustration of where by abstracting away the details of file formats drastically can help stop consumers is compression. An capability to transparently modify the underlying illustration of data to obtain greater compression interprets to storage price savings, compute price savings, and greater effectiveness. Exposing the details of file formats can make it future to impossible to roll out greater compression without having incurring long migrations, breaking improvements, or extra complexity for applications and builders. 

Related concerns crop up when we consider about enhancements to stability, data governance, data integrity, privacy, and numerous other places. The historical past of database programs gives a great deal of examples, like iSAMS or CODASYL, displaying us that bodily access to data leads to an innovation useless stop. A lot more not too long ago, adopters of Hadoop discovered by themselves handling pricey, advanced, and unsecured environments that did not produce the promised effectiveness.

In a globe with immediate file access, introducing new abilities interprets into delays in acknowledging the added benefits of these abilities, complexity for application builders, and, likely, governance breaches. This is an additional point arguing for abstracting away the internal illustration of data to give far more benefit to prospects, whilst supporting ingestion and export of open file formats. 

Open protocols and APIs

Data access strategies are far more critical than file formats. We all concur that preventing seller lock-in is a key consumer priority. But whilst some imagine that open formats are the solution, the heavy lifting in any migration is seriously about code and data access, no matter whether it is protocols and connectivity motorists, question languages, or business logic. These who have gone via a system migration can probable attest that the matter of file formats is a purple herring.

For us, this is where by open matters most — it is where by pricey lock-in can be averted, data governance can be maximized, and higher innovation is possible. Focusing on open protocols and APIs is key to preventing complexity for consumers and enabling steady, transparent innovation.

Open supply

The added benefits cited for open supply include things like a higher comprehending of the technologies, amplified stability via transparency, lower expenses, and group improvement. Open supply can produce in opposition to some of these aims, and does so principally when technologies is installed on-premises, but the change to managed solutions significantly alters these dynamics.

When it comes to higher comprehending of code, take into consideration that a subtle question processor is usually created and optimized around a number of several years by dozens of Ph.D. graduates. Generating the supply code available will not magically allow its consumers to recognize its internal workings, but there may be higher benefit in surfacing data, metadata, and metrics that give clarity to prospects.

One more aspect of this dialogue is the motivation to copy and modify supply code. This can give benefit and optionality to companies that can commit to build these abilities, but we’ve also observed it lead to unwanted implications, which include fragmented platforms, considerably less agility to employ improvements, and competitive dysfunction. 

Improved stability

This has customarily been one particular of the main arguments for open supply. When an group deploys software package in just its stability perimeter, supply code availability can in fact increase self confidence about stability. But there is a rising consciousness of the threats in software package provide chains, and advanced technologies methods often aggregate a number of software package subsystems without having an comprehending of the complete stop-to-stop influence on stability.

Fortunately there is a greater model, which is the deployment of technologies as managed cloud solutions. Encapsulation of the internal workings of these solutions lets for a lot quicker evolution and speedy shipping of innovation to prospects. With extra concentrate, managed solutions can remove the configuration load and eradicate the hard work needed for provisioning and tuning. 

Decrease expense

Most companies have acknowledged by now that not paying a software package license does not necessarily mean lower expenses. Apart from the expense of upkeep and assistance, it ignores the expense and complexity of deploying, updating, and split-repairing software package. Charge must be measured in terms of total expense and selling price/effectiveness out of the box. In this article, too, managed solutions are preferable, eradicating amid other matters the need to have to deal with versions, work about upkeep windows, and good-tune software package.


A single of the most strong aspects of open supply is the notion of group, by which a group of consumers work collaboratively to improve a technologies and support one particular an additional. But collaboration does not need to have to suggest supply code contribution. We consider of group as consumers aiding one particular an additional, sharing finest procedures, and speaking about upcoming directions for the technologies. 

As the change from on-premises to the cloud and managed solutions carries on, these matters of regulate, stability, expense, and group recur. What is exciting is that the initial aims of open supply are being fulfilled in these cloud environments without having necessarily offering supply code for everyone—which is where by we commenced this dialogue. We will have to not lose sight of the wanted results by focusing on tactics that may no for a longer time be the finest route to these results.

Open at Snowflake

At Snowflake, we consider about initially ideas, about wanted results, about supposed and unintended implications, and, most importantly, about what is finest for our prospects. As these types of, we never consider of open as a blanket, non-negotiable attribute of our system, and we are very intentional in selecting where by and how we embrace it. 

Our priorities are very clear: 

  1. Supply the greatest degrees of stability and governance 
  2. Deliver business-top effectiveness and selling price/effectiveness via steady innovation and 
  3. Established the greatest degrees of quality, abilities, and ease of use so our prospects can concentrate on deriving benefit from data without having the need to have to deal with infrastructure. 

We also want to ensure that our prospects go on to use Snowflake since they want to and not since they are locked in. To the extent that open requirements, open formats, and open supply support us obtain these aims, we embrace them. But when open conflicts with these aims, our priorities dictate in opposition to it.

Open requirements at Snowflake

With these priorities in mind, we have entirely embraced common file formats, common protocols, common languages, and common APIs. We’re intentional about where by and how we do so, and we have invested intensely in the capability to leverage the abilities of our parallel processing motor so that prospects can get their data out of Snowflake speedily must they need to have or choose to. However, abstracting away the details of our lower-degree data illustration lets us to continually improve our compression and produce other optimizations in a way that is transparent to consumers. 

We can also advance the controls for stability and data governance speedily, without having the load of handling immediate (and brittle) access to data files. In the same way, our transactional integrity added benefits from our degree of abstraction and not exposing underlying data files directly to consumers. 

We also embrace open protocols, languages, and APIs. This includes open requirements for data access, standard APIs these types of as ODBC and JDBC, and also Rest-centered access. In the same way, supporting the ANSI SQL common is key to question compatibility whilst supplying the energy of a declarative, increased-degree model. Other examples we embrace include things like enterprise stability requirements these types of as SAML, OAuth, and SCIM, and several technologies certifications.

With proper abstractions and marketing open where by it matters, open protocols allow us to shift a lot quicker (since we never need to have to reinvent them), allow our prospects to re-use their expertise, and permit rapid innovation due to abstracting the “what” from the “how.” 

Open supply at Snowflake

We produce a compact variety of factors that get deployed as software package methods into our customers’ programs, these types of as connectivity motorists like JDBC or Python connectors or our Kafka connector. For all of these we give the supply code. Our intention is to permit greatest stability for our prospects, and we do so by delivering our main system as a managed support, and we increase the peace of mind for installable software package via open supply.

However, a misguided application of open can build pricey complexity rather of lower-expense ease of use. Supplying steady, common APIs whilst not opening up our internals lets us to speedily iterate, innovate, and produce benefit to prospects. But prospects can not create—deliberately or unintentionally—dependencies on internal implementation details, since we encapsulate them at the rear of APIs that comply with good software package engineering procedures. That is a key benefit for both of those sides, and it is key to maintaining our weekly cadence of releases, to steady innovation, and to useful resource effectiveness. Customers who have migrated to Snowflake inform us continually that they respect these selections.

The interface to our entirely managed support, run in its very own stability perimeter, is the deal amongst us and our prospects. We can do this since we recognize each part and commit a terrific amount of methods to stability. Snowflake has been evaluated by stability groups across the gamut of corporation profiles and industries, which include hugely regulated industries these types of as health care and financial services. The system is not only protected, but the separation of the stability perimeter via the clean up abstraction of a managed support simplifies the job of securing data and data programs for prospects.

On a final notice, we like our person teams, our consumer councils, and our person conferences. We entirely embrace the benefit of a vibrant group, open communications, open community forums, and open discussions. Open supply is an orthogonal idea, from which we do not shy away. For instance, we collaborated on open sourcing FoundationDB, and built major contributions to evolving FoundationDB further more. 

However, we never extrapolate from this to say there is an inherent advantage to open supply software package. We could equally have utilised a diverse operational retailer and a diverse model of earning it to match our requirements if needed. The FoundationDB instance illustrates our key thesis: Open is a terrific collection of initiatives and processes, but it is one particular of numerous applications. It is not the hammer for all nails and is the finest alternative only in some circumstances.