Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Cloud Services / Data / Software Development

Microsoft Announces PostgreSQL Option for Cosmos DB

Microsoft adds a relational option to its geo-distributed cloud NoSQL database. And it's Postgres, not SQL Server, that won Cosmos DB's hand.
Oct 12th, 2022 9:20am by
Featued image for: Microsoft Announces PostgreSQL Option for Cosmos DB

At its Ignite conference in Seattle today, Microsoft CEO Satya Nadella announced new PostgreSQL support for Azure Cosmos DB. While Cosmos already supported a number of interfaces and APIs for NoSQL database technologies, this announcement marks the first time a true relational database solution is being offered on the platform. Microsoft says it also makes Azure the first cloud platform to support both relational and NoSQL options on the same service.

I’ll cover the news in some technical depth here. For folks who want to drill down even further, the Cosmos DB team told me it’s hosting a two-hour online event on Oct. 18, with content on strategy, concepts and how-to, for the new Postgres offering.

Two Databases in One?

TNS spoke with Rohan Kumar, Microsoft’s Corporate Vice President, Azure Data, about the announcement and got some interesting architectural details. To cut to the chase: Kumar explained Azure Cosmos DB for PostgreSQL (a Microsoft product name if ever there were one) is a mashup of sorts, with Cosmos DB laying the infrastructural foundation and Microsoft’s distributed PostgreSQL engine, obtained when it acquired Citus Data in 2019, on top. “We… have taken the distributed query processing engine of Citus… and effectively have that overlaid on top of Cosmos DB,” Kumar said.

That makes the Cosmos/Postgres offering unlike any of the Cosmos API options, be it Core SQL, Azure Table storage for key-value access, MongoDB for document store applications, Gremlin for graph database workloads, or Cassandra for wide column store implementations. All of those options essentially present different language/wire protocol/API combinations around the same core technology, while the Postgres option offers a completely different query engine. Maybe that’s why it’s called Cosmos DB for PostgreSQL, and not the other way around.

Compatibility’s Extent

There are some ramifications here that are important to take stock of. First off, according to Kumar, this is “actually the Postgres engine” and not merely a compatibility layer. Kumar went on to explain that what attracted Microsoft to Citus was that “they were not really giving up on compatibility with Postgres. That was important because, you know, if you take the Postgres engine and you change it up completely then, well, it’s not Postgres anymore.” Kumar added: “We really liked their approach of using the extensibility model of Postgres to maintain compat[ability] while enabling… a database that underneath the covers was sharded.” (Sharding is a foundational technique in scaling out and partitioning databases across multiple servers.)

That also means compatibility with the broad array of Postgres extensions will be present as well. Of course, since Cosmos DB is a managed platform, the extensions actually made available will be the ones Microsoft chooses. I asked about one in particular — PostGIS, a very popular geospatial database extension for Postgres. Kumar said PostGIS will indeed be supported, as will several others, prioritized based “on their usage.”

The use of the Citus engine also means full support for Postgres’ SQL dialect and, given the relational nature of the database, full ACID compliance — i.e. full query consistency, and not the “eventual consistency” model supported in many NoSQL platforms, nor even the sliding scale consistency offered within the other Cosmos DB interfaces.

While Kumar said “today we basically support globally distributed read semantics,” there are some other customary Cosmos features that Cosmos DB for Postgres won’t get, at least initially. But Kumar said, “we are working on further enhancing and adding more and more capabilities.” He also told me Cosmos for Postgres users will get the same service level agreements (SLAs) that are extended to all Cosmos DB customers.

Which Postgres?

There’s one more piece to this story that’s very interesting. Cosmos DB for PostgreSQL will replace Azure Database for PostgreSQL — Hyperscale. In fact, Microsoft told me that “all [PostgreSQL — Hyperscale] customers and workloads will automatically move to Azure Cosmos DB for PostgreSQL.” That’s a big deal. It means that Cosmos DB for PostgreSQL will now be the Citus distributed Postgres option. It also means Cosmos DB is gradually becoming Azure’s unified hyperscale database platform.

This begs a question: for users who want to cloudify their conventional Postgres applications and move them to Azure, is a lift-and-shift to Cosmos DB for PostgreSQL possible? Can that elusive “just change your connection string and run the same code” scenario be supported here?

Kumar’s response was essentially that while customers could carry out such migrations, they wouldn’t necessarily see much benefit or cost-effectiveness by doing so unless their application had the need for a globally-distributed database like Cosmos DB, or would grow into having that need. So while Kumar didn’t say it in so many words, it would appear that customers should consider Azure Database for PostgreSQL and Cosmos DB for PostgreSQL as a pair of compatible options, each of which addresses different database scale use cases.

Don’t Neglect the Base

And speaking of Azure Database, what about Azure SQL Database (the cloud implementation of SQL Server) and its T-SQL language? Why wouldn’t Microsoft choose that dialect and interface as its first relational head on Cosmos? And, regardless, does Microsoft have plans to add it?

I asked Kumar that question too. His answer, essentially, was never say never. While T-SQL/SQL Server support is not on the roadmap, Microsoft won’t rule it out. Meanwhile, Microsoft’s read of how to get more market share for Cosmos DB was to get a popular open source database supported first, with the acknowledgment that lots of applications and services out there use Postgres, and those are the prospective customers Microsoft apparently is after.

That’s a reasonable calculus, but the company also needs to cater to its core community base. SQL Server professionals had already looked sideways at Cosmos when it was introduced and that created a certain estrangement. Welcoming that same community and ecosystem into the Cosmos fold would make a lot of sense, and likely help the platform.

That’s exactly what happened when Microsoft enabled Power BI with the full complement of features that SQL Server Analysis Services (SSAS) always had. Yes, Power BI was already wildly popular, but bringing the SSAS community, and its skillsets, to Power BI added enterprise gravitas to the platform, enlarged the tent, and defragmented the Microsoft BI community. The Cosmos DB team and the broader Microsoft Intelligent Data Platform team (which has a lot of Power BI lineage to it) might want to consider whether the situation with Cosmos and SQL Server could be analogous.

Disclosure: Post author Andrew Brust is a Microsoft Data Platform MVP and member of Microsoft’s Regional Directors Program for independent influencers. His company, Blue Badge Insights [], has done work for Microsoft, including the Power BI team.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.