What’s a server? What’s a database? What’s a schema? … and a table?
Let’s make some order here:
- Server: When I started working in IT, back in 2012, it took me a while to understand that a server is basically a computer. But that’s it, a server is a computer. At the very beginning they were mere computer towers, positioned below a desk, warming the developer’s feet with their fan during working hours.
But then internet came along bringing Mail servers and Web servers. And people wanted to read their mails at night and visualize websites at any time. Also because probably someone was visiting the website from another time zone.
So let’s make those PC run 24/7. and because the carpet is full of dust let’s squeeze them all into a closet. We will eventually dedicate a room to them later on…
- Database: The cylinder shaped icon comes from the fact that they were magnetic disc storage one upon each other. And they were the very first hard drives too. That’s why, still today, when you want to restore a backup in SSMS the GUI will prompt you with the “Device”. Like “…attach that device to me!”. Today a backup is a simple file on a file system but before you physically had to connect the hardware database.
Fun fact: do you know why in Windows the hard drive is called “C:\” ?
Because “A:\” was the slot you used for the OS (yes, you had to insert the OS every time); “B:\” was the slot you used to copy file in case you had to copy or extract files from the “A:\” drive.
In the middle of the ’90, when the OS didn’t needed a dedicated file system any more “C:\” was the next letter available and they used that to keep backward compatibility for A and B.
- Schema: The schema of a database is a virtual representation of the relationship between the data within a database. That is the reason why in Hierarchical database the schema has a tree model: that’s because there is a Hierarchy.
In the other hand in RDBMS there is no Hierarchy and you can create much complex relation between objects.
- Table: In relational database terms, a table is responsible for storing data in the database. Database tables consist of rows and columns. Is not different to what you see in Excel or in Access. (But I hope you have uninstalled Microsoft Access from your computer ages ago…).
In SSMS if you export a database as
.bacpacand then you rename the extension
.zipand extract the content you will see how each table is represented as a folder in which you can see the raw data.
…but what this fuss is all about?
Well, if you are migrating SQL Server databases to Azure there is no problem.
You still have to create a SQL Server and that server contains the databases. Creating a SQL Server in Azure id free and or each database I’m paying $7.50 per month, the lower price.
In this example I have created a server called
jeejamigrationtest to which I have migrated 3 databases:
And this is what I have on Azure after migration, a server that contains 3 databases. All good.
If I click on each database I can:
- see fancy metrics about DTU consumption
- change the Pricing tier and scale up or down CPU, RAM and throughput
- manage backup retention
- manage replication
A server contain databases… all good here… Let’s try to do the same with….
Azure Database for MySQL server
The first punch in the eye is the price: $49.60 for a MySQL Server (against the $0 for SQL Server.)
The databases are uploaded from Workbench to Azure quickly, without asking to what tier you want to put them.
Once again everything looks fine. Just like with SQL Server we have a Server that now contains my recently migrated databases.
After the databases are uploaded I discover with horror that their fields are unclickable: I cannot managed the databases one by one.
The replica is called “Read Replica” and just by the name I see that this will never be a writeable replica in case of Disaster Recovery.
But where are the backups? There are no backups!
If you want to restore something you have to restore the whole
And you cannot even restore it to the same instance: you have to create a new instance, pay the $49.60 and restore. A procedure that in case of a disaster will take minutes to complete. And if you just want to check one of your backups you need to have a new server and pay the $49.60. This is crazy!
- the fancy metrics about DTU consumption are not about a single database but the whole
- you cannot change the Pricing tier, so basically you cannot scale. You have to scale the whole
- you cannot backup a database but you have to backup the whole
- replications are in a read only state so Disaster Recovery plan are impossible to setup
etc…there is no “etc…” because there is nothing else
So let’s label things with their right name:
If you think you could migrate your databases to MySQL on Azure think twice because the options are very reduced.
There is no way you can setup a single-tenant solution because multi-tenant is the only option.
Do you still want to use single-tenant solution? You have to buy one of these
server things for each database you want to migrate to Azure. And if you compare the prices it doesn’t worth.
The cherry on the cake? If you want to stop the
server thing it will automatically resume after 7 days for no reason.
Well, there is one reason… they want you to hate open source alternatives.
The stick and the carrot
Microsoft is working hard to make you hate open source software.
The philosophy that Microsoft is using here is the stick and the carrot: on one side you have free SQL Server and databases at insignificant price. On the other side you have a true hell. Let’s sum it up in a clear price table:
|Azure SQL Database||Azure Database for MySQL||Azure Database for MariaDB||Azure Database for PostgreSQL|
|7.50 NZD||49.60 NZD||82.60 NZD||50.59 NZD|
And if you want to craeate a second replica just multiply x2 the price.
If you think open source is free, well, not on the cloud