4 ms·

RDS for SQL Server does have some features missing from Azure SQL Database (SSAS and time zones as you said, but also SSRS). As a PaaS service it's pretty rough

by Uvix 3y ago

RDS for SQL Server does have some features missing from Azure SQL Database (SSAS and time zones as you said, but also SSRS). As a PaaS service it's pretty rough around the edges, though: scaling requires a long outage, copying a database between servers requires doing a backup to S3 and restoring from that, and the AWS backup/restore operates on the server level rather than the database level. Where AWS really showed its unsuitability to host applications on the Microsoft stack was that AWS doesn't have a PaaS way to host .NET Framework web applications; IaaS is the only option. So both .NET Framework web application nor Microsoft SQL Server database were noticeably harder on AWS than Azure for us. Standing up one IaaS server to host SSRS in Azure was a lot less work than accounting for all the gaps on the AWS side would have been.

jiggawatts 3y ago
Azure SQL database doesn’t support .BAK files. It can only import or export in BACPAC format which is SQL statements in a zip file and is an order of magnitude slower to restore. We’ve had issues where large databases would take forever to cut over to the PaaS database and cause long outages during migrations. It’s these random feature gaps that make these platforms difficult to deal with.
- Uvix 3y ago
  BACPACs are the only option to get a database out of Azure SQL. And yes, they do suck, for the reasons you outlined. For the initial migration to PaaS, whether Azure or AWS RDS, it’s faster and easier to use replication instead of BACPACs. For moves within the Azure SQL environment, they have database copy functionality that can be utilized. (Which RDS doesn’t have, and I would have sorely missed if we hadn’t pulled the plug on AWA.)
  - jiggawatts 3y ago
    Replication is a breaking schema change, and incompatible with a long list of features and applications.
  - whizzter 3y ago
    There's a better way to get data out of Azure if you can handle a bit of manual scripting (way worth if for large tables). Setup linked-servers from your local server (via Server Objects / Linked servers), once you've done that you can just do "INSERT INTO bigtable(..) SELECT .. FROM [remotename].dbo.bigtable;" , it'll tax the transaction log but it's a magnitude faster than bacpac's,etc. Sadly Azure SQL doesn't support linked servers so one of the servers has to be outside.

by Uvix 3y ago

jiggawatts 3y ago

Azure SQL database doesn’t support .BAK files. It can only import or export in BACPAC format which is SQL statements in a zip file and is an order of magnitude slower to restore. We’ve had issues where large databases would take forever to cut over to the PaaS database and cause long outages during migrations. It’s these random feature gaps that make these platforms difficult to deal with.

Uvix 3y ago
BACPACs are the only option to get a database out of Azure SQL. And yes, they do suck, for the reasons you outlined. For the initial migration to PaaS, whether Azure or AWS RDS, it’s faster and easier to use replication instead of BACPACs. For moves within the Azure SQL environment, they have database copy functionality that can be utilized. (Which RDS doesn’t have, and I would have sorely missed if we hadn’t pulled the plug on AWA.)
- jiggawatts 3y ago
  Replication is a breaking schema change, and incompatible with a long list of features and applications.
- whizzter 3y ago
  There's a better way to get data out of Azure if you can handle a bit of manual scripting (way worth if for large tables). Setup linked-servers from your local server (via Server Objects / Linked servers), once you've done that you can just do "INSERT INTO bigtable(..) SELECT .. FROM [remotename].dbo.bigtable;" , it'll tax the transaction log but it's a magnitude faster than bacpac's,etc. Sadly Azure SQL doesn't support linked servers so one of the servers has to be outside.