The pricing table above may scare you off and you may immediately think of not going through the embedded path. However, I need to let you know that there are some scenarios which Power BI Embedded can be a much more cost-effective option than Pro. Here is an example:
Assume that you have 100 users for your Power BI solution. And your users are not connecting all at the same time to use Power BI reports. You may have the maximum of 300 page renders per hour for them if you use embedded. In such case, embedded for that scenario would cost you about $700 USD per month, where the Power BI Pro for 100 users would be $1000 USD per month. This means saving of $3,600 USD per year. This is an example scenario that Power BI Embedded can be more cost-effective than Pro.
Give this a careful reading if you’re looking to implement Power BI in your environment.
Starting with SQL Server 2017, we are adopting a simplified, predictable mainstream servicing lifecycle:
- SPs will no longer be made available. Only CUs, and GDRs when needed.
- CUs will now accommodate localized content, allowing new feature completeness and supportability enhancements to be delivered faster.
- CUs will be delivered more often at first and then less frequently. Every month for the first 12 months, and every quarter for the remainder 4 years of the full 5-year mainstream lifecycle.
- CUs are delivered on the same week of the month: week of 3rd Tuesday.
Note: the Modern Servicing Model (MSM) only applies to SQL Server 2017 and future versions.
If you’re the type who waits for SP1 to drop, you’ll be waiting for Godot. Who should be here any minute now.
Standard edition is limited to lesser of 4 sockets or 24 cores with a maximum memory of 128 GB plus a few truly Enterprise level features like Compression, Availability Groups, Partitioning etc are off limits. I would say most places would fall under this threshold for “Standard” but feel inferior to say they run “Standard”! I don’t, especially when money matters.
But, all kidding aside, most shops don’t even realize that they do not use any Enterprise features on 90% of their instances but pay Enterprise price anyway! If you don’t trust me, go check for yourself at your place – we did, on hundred’s of SQL Server instances! I painfully built the infrastructure to do this type of thing using PowerShell in seconds if not a few minutes, for scanning hundreds of servers/instances.
There’s a lot here, so if you’re thinking about downgrading in a post-2016 SP1 world, Jana’s post is a must-read. But even with the new features, there are still quite a few enterprise-level features that make it so I don’t want to live without Enterprise Edition.
I think the existence of the Power BI Free product has been the root of the problem here. The fact that you could do so much for free (including some sharing) really muddied the waters and has taken the focus away from acknowledging that there needs to be a two tier pricing model for users (free is not a pricing tier). Microsoft is addressing one part of the problem by making it clear that Power BI Free is for personal (non sharing) use. However it has not addressed the second part of the problem being the need for a lower priced offering for users that just consume data in a way I would describe as “low involvement”. Microsoft has taken away the “proxy for a low priced sharing tier” without providing a genuine low priced replacement – this had just made the situation worse, not better and it has upset a lot of people. Power BI Free has been a great product to “try before you buy” but unfortunately its existence prevented Microsoft from realising it was missing a price tier for 2 years! Power BI Free for personal use (no sharing) is an incredibly generous offering from Microsoft. It is a shame that it will need a backlash to fill the real gap – a lower priced tier.
Check out the comments as well. I think Matt has a good point, and my guess is that the Power BI team will make it easier for small to medium sized businesses to use Power BI, but they first wanted to focus on the problem with big customers.
Included in the recent list of announcements Microsoft made about Power BI Local and Power BI Premium are a series of changes to the Power BI Free version which will go into effect on June 1. The free edition of Power BI will no longer be able to share reports. Currently free users could create reports and share them with others, which will be discontinued. Only Power BI Pro Editions will be able to share reports. Currently Power BI Pro users can create reports which can be shared with Free versions as long as no Pro features are used. This means that if a Power BI report is set to automatically refresh the data, that report cannot be shared as Free versions do not have the ability to create reports which have data refreshed automatically. If the report was recreated to remove the automatic updates and instead refreshed manually, then the report could be shared with Free versions. Starting June 1, the sharing feature will be removed. No longer can Power BI Pro users share anything to Power BI Free users. If you have a Power BI Free account, there is no way to share information in the service. The Power BI Desktop will continue to be free but since you cannot print the content within it and sharing a PBIX file means that you will always be sharing the entire data model, this is of limited value.
Read the whole thing.
Hidden schedulers are used to process requests that are internal to the engine itself. Visible schedulers are used to handle end-user requests. When you run the casual SELECT * query, it will utilize a visible scheduler to process the query. With this information, if I have a 64 core server and all is well, I should have 64 visible schedulers online to process requests.
However, I discovered that some of the schedulers were set to “VISIBLE OFFLINE”. This essentially means that those particular schedulers are unavailable to SQL Server for some reason. How many offline schedulers do I have? A quick query resulted in 24 schedulers currently offline. 24 logical cores means that 12 physical cores are offline.
But why would a scheduler be set to “VISIBLE OFFLINE”?
Read on for the answer, and check the comments for a helpful plug for sp_Blitz.
The DTU Calculator, a third-party service created by Justin Henriksen (a Microsoft employee), will calculate the DTU requirements for our on-premises database that we want to migrate to Azure, by firstly capturing a few performance monitor counters, and then performing a calculation on those results, to provide the recommended service tier for our database.
Justin provides a command-line application or PowerShell script to capture these performance counters:
Processor – % Processor Time
Logical Disk – Disk Reads/sec
Logical Disk – Disk Writes/sec
Database – Log Bytes Flushed/sec
For more details on DTUs, John Sterrett looks at the math.
- “A minimum of 16 core licenses is required for each server.”
- “A minimum of 8 core licenses is required for each physical processor.”
When most sysadmins see that, they’ll think, “Okay, so I shouldn’t bother buying a server smaller than 2 8-core processors.”
There are plenty of scenarios in which this doesn’t hurt (much): mainly when you need a hefty server with more than 16 cores, or when you are running in a virtualized environment and can split that hardware across a number of logical servers.
As for me, this is one reason why I’m looking forward to SQL Server on Linux.
Copied from somewhere else on the internet, this PowerShell script will return the product key used for a SQL instance Install. Super useful when changing licenses on temporary VM’s I spin up and play around with to SQL Developer whose instances have passed the Enterprise evaluation use-by date. Putting this here for my own benefit. I claim no kudos!
Click through for the code.
When I see those numbers in Microsoft marketing slides, I sometimes wonder if they can be real, but then I put these numbers together myself. Granted you would get some discounts, but the fact that all of these features are built into SQL Server, should convince you of the value SQL Server offers. Pricing discounts are generally similar between vendors, so that is not really a point of argument. If you are doing a really big Oracle deal you may see a larger upfront discount, but you will still be paying your 23% support fees on that very large list price. (Software Assurance from Microsoft will be around 20%, but from a much lower base) Additionally, several of these features ae available in SQL Server Standard Edition. None of these features are in Oracle’s Standard Edition.
Postgres is a really good database engine, with a rich ecosystem of developers writing code for it. SQL Server on the other hand, is a mature product that has had a large push to support analytic performance and scale.
Additionally, this customer is leveraging the Azure ecosystem as part of their process, and that is only possible via SQL Server’s tight integration with the platform.
This isn’t a direct comparison to help determine in some absolute sense which product is better, but rather looking at a use case from a customer which takes advantage of many of the features in SQL Server.