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.

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.

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.

One thing to consider is when customers should be using this new service and when they should use Azure Database for PostgreSQL — Hyperscale instead. Both services use the Citus distributed engine on top of standard Postgres and both use a distributed, scale-out architecture. 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, Azure Database for Postgres SQL Hyperscale and Cosmos DB for PostgreSQL as a spectrum of compatible options.

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 [www.bluebadgeinsights.com], has done work for Microsoft, including the Power BI team.