Chamath Palihapitiya

Chamath Palihapitiya

Multi Model SQL Server

Graph database

SQL Server is introducing graph support. What I find great, is that you can mix it in your traditional relation database, so there’s no big to-SQL or NoSQL decision necessary.

This makes graphs a very feasible option in Microsoft (eco)systems, since you can start using this transparently to your IT infrastructure/department. Standard SQL Server operation and maintenance¬† procedures apply, no need to go through the pains of introducing an “exotic” to them database which noone has any experience running in production.

Document store

That’s in SQL Server 2017, what I totally missed in 2016 though, is the built-in JSON support. And I thought Marten was unique for .NET with its approach of exploiting the JSON support in Postgresql, to create a robust document store.

NoSQL – No SQL Server Marketing

I don’t have any experience with the graph or JSON support in SQL Server yet, so I might be missing something. And I’m sure a pure bred NoSQL product can go an extra mile or more. But I get the impression SQL Server responded to the NoSQL hype, and then didn’t really sell its new features to .NET developers.

Just last month at work, we were still discussing MongoDB to store documents and weighing whether taking on a new database technology in a Microsoft shop would be worth it, and we didn’t even consider SQL Server as a document option!

Obviously you can always build your own solution in SQL Server, but who has the time for that.

Now Cosmos DB markets itself as the all-in-one database for the cloud, but on-premise it looks like SQL Server will still get you from A to B.

Theme music for this blog post


Multi Model SQL Server