You’ll notice that we’ve been blogging and writing a lot about Google here this week. I gotta tell you – it’s totally bizarre sitting in a Google Cloud Next conference session in San Francisco, watching presenters using Macs, coding with Visual Studio Code, demonstrating SQL Server.
I even talked to a SQL Server DBA attendee yesterday who said, “My employer won’t send me to PASS, but they sent me here because they’re thinking about moving everything to the cloud, and they want me to be ready.”
Yes, this stuff matters to you.
Now, with that out of the way, let’s get started. In managed platform-as-a-service databases like Microsoft Azure SQL DB, Amazon Relational Database Service (RDS), and Google Cloud Spanner, the vendor takes care of basic care and feeding like:
- Backups, restores, and corruption checking
- Hardware & storage provisioning and maintenance
- OS & database patching
- And all the really boring stuff you never really liked to do anyway
Developers love PaaS databases because, uh, they hate DBAs. I mean, they don’t hate us as people – especially when we can help make their apps go faster – but we’re often labeled as Don’t Bother Asking because all we do is say no. With PaaS databases, nobody says no. (That’s totally not true – it’s just that the vendor’s the one saying no, and it’s really clear black-and-white, as in no, that feature simply isn’t turned on for anyone in the world. It’s not just you.)
SQL Server DBAs haven’t worked much with PaaS.
In the Microsoft space – where you, dear reader, probably make your living as do I – platform-as-a-service means Azure SQL DB. That’s been a total non-starter for migrating most existing apps over because it requires so much work:
- Different T-SQL coverage area – like Azure SQL DB’s painful cross-database query setup, or different ways of scheduling Agent-type jobs
- Different (and changing) feature support – like no SSIS, or SSRS, or when Azure SQL DB removed support for SQLCLR
So you probably haven’t seen your developers racing to convert their SQL Server apps over to Azure SQL DB. (I’d argue that for building a new SQL Server-based app, though, you should default to Azure SQL DB first. Although if you’re building any app, you should look at the PaaS options out there – for example, we’re using PostgreSQL for our new development. No, don’t worry, we won’t turn this into a PostgreSQL site.)
But away from Azure SQL DB, things are different.
I have to say this because if you read SQL Server blogs, they’re likely written by SQL Server folks who spend the vast majority of their time focused on the Microsoft ecosystem. (That’s especially true of MVPs – Microsoft heavily markets Azure to them, and encourages them to blog about Azure.)
When you get away from Azure SQL DB, there’s a very different story happening in the rest of the database community. Developers who built their apps on MySQL and PostgreSQL, the two big open source databases, have all kinds of cool options on where to host their apps with dramatically fewer (or no) code changes:
- Amazon Relational Database Service is hosted/managed MySQL, PostgreSQL, MariaDB, Oracle, and yes, SQL Server
- Amazon Aurora is MySQL and PostgreSQL compatible, but actually a different storage layer underneath, giving you performance and scalability capabilities you didn’t even have with those databases (seriously, the Aurora promo video is the best explanation I’ve ever seen for PaaS databases)
- Heroku Postgres is managed PostgreSQL, got a lot of early traction because Heroku offered a lot of cool services for developers, but that’s fallen off the radar lately
Developers can just take their MySQL/PostgreSQL apps, forklift ’em up into the cloud, and run them as-is. That’s pretty doggone compelling. That’s why PaaS databases are on fire – outside of the Microsoft market.
Today, Google announced Cloud SQL, their competitor.
Today at Google Cloud Next this morning in San Francisco – it’s like their Microsoft Build – Google announced Cloud SQL, their own managed PostgreSQL database-as-a-service in beta.
Cloud vendors are racing for managed support of every database – including SQL Server. If your existing app’s database will work up in their cloud, then you can move your entire workload up to their cloud – and that’s what they want.
In the day 1 keynote, Eric Schmidt – the chairman of Alphabet – focused entirely on databases. His whole point was that if you can get your valuable data unlocked from your on-premises proprietary database, and get it up into the open cloud, then you can run all kinds of analytics and machine learning against it. He said you’ll want to use Google’s team – not just their services, but their team, touching on their acquisition of Kaggle – to help unlock the value.
He wasn’t talking about lowering costs or reducing staff. He was talking about adding value. (This is a refreshing change from earlier cloud vendor marketing that kept touting reduced costs, which frankly almost never happens when you move an existing company up to the cloud. It totally does happen for new businesses, though – I ain’t buildin’ no data center.)
So what do Microsoft SQL Server pros need to take away?
Imagine if you were a PostgreSQL DBA and you saw these things happening. You’d probably be scared for your job.
In reality, PostgreSQL people still have a huge amount of work ahead of them. (As an HSBC exec said during the day 1 keynote, the hardest part is finding people who can use all these data tools.) Their jobs won’t change tomorrow, but they will gradually change over the coming years. The crappy part of database administration – backups, recovery, patching, failovers – become the vendor’s job. That’s awesome.
Do SQL Server DBAs need to learn PostgreSQL? If you’re already a DBA, no. Your job is still safe working in the Microsoft SQL Server stack. Even if you do want to jump ship, be careful which parts you learn. I wouldn’t want to focus my career on the internal plumbing, the parts that the cloud is abstracting away anyway. Focus on things like query construction, tuning, and index design.
Do SQL Server developers need to consider PostgreSQL? Probably yes, the next time you start a project. Developers are in the business of constant learning. Every time they start a new project, they consider new frameworks, languages, and persistence layers. I don’t think you have to pick up a good PostgreSQL book yet, but I think you should at least know that the option is out there – and it’s a good one.