Microsoft has entered the final phase of retiring Azure SQL Data Sync, blocking new deployments in subscriptions that have never used the service. The restriction took effect on September 9, ahead of the service's shutdown on September 30, 2027. Subscriptions that already use the service can continue creating, modifying, and managing sync groups and member databases until retirement. Other subscriptions can no longer adopt it. The service uses a hub-and-spoke model, with an Azure SQL database serving as the hub and other databases joining its synchronization group. Members can be other Azure SQL databases or on-premises SQL Server databases, which require a sync agent. A conflict resolution policy determines whether the hub or member database takes precedence when changes clash. SQL Data Sync supports scenarios including hybrid environments, in which applications and databases are split between local infrastructure and Azure, as well as geographically distributed applications. Microsoft acknowledged that customers will need to choose among several possible replacements. It offered little technical explanation for the retirement, referring only to evolving "operational, security, and compliance requirements." Microsoft announced the retirement two years ago, but blocking first-time deployments gives customers another reason to begin planning their transition. Microsoft lists alternatives including Azure Data Factory, Azure Functions, read replicas, linked servers, database mirroring, availability groups, and transactional replication. However, it noted that "there is no single replacement that maps to every SQL Data Sync configuration." Existing users have just over a year to migrate before the final cutoff. Those without a migration plan will need one before the service shuts down. ®

PostgreSQL 19 is set to add standardized SQL syntax for querying property graphs. The open source database has steadily grown in popularity over the last five years, becoming the most popular among developers for the first time in 2023. Speaking to The Register, Alastair Turner, PostgreSQL evangelist at open source consultancy Percona, said the property graph query support in PostgreSQL 19 – due later this month or early October – resulted from collaboration among several of the database's largest contributors. Graph databases store data as nodes, relationships, and properties rather than tables or documents. They have advantages for certain workloads, but adopting one can mean adding another DBMS to the technology stack. The relational database has been acquiring graph query capabilities for some time, but PostgreSQL 19 is set to go further, Turner explained. "All the rest of it has sort of been done through Object Relational Mapping over the top. This is actually baked-in graph syntax. It comes from the SQL 2023 standard." Turner said the implementation was "very heavily influenced" by some of the engineers behind OpenCypher, the open source query language for graph databases. The work also involved PostgreSQL committers who sit on the SQL standards committee. "This is one of the most interesting developments because it's one of the big multi-vendor collaborations. There was lots of coding and review work across quite a few of the big contributors," he said. The new capability implements SQL/PGQ, which became part of the SQL standard in 2023. "It's on the right path," Turner said. "The SQL community and the PostgreSQL community are going to try to optimize everything." However, he added that the implementation "still needs one or two additional syntax features" before it can displace dedicated graph databases for a significant number of workloads. Turner said: "The current implementation creates queries across node-edge graphs to satisfy those requests. So some of them perform very well. What's going to have to happen in the next iteration or two is that indexing add-ons catch up to improve the performance." ®