November 8, 2018 at 1:10 am
If you are looking at serverless for individual developers its interesting
In MS Azure for me at November 2018 a BASIC managed instance of SQL Server (enough to start developing against yet completely removes the barrier to upscaling) 5DTUs and 2GB is £3.6499 a month and then to upscale to S0 10 DTUs with 250GB I am looking at £10.97 a month.
The cheapest managed instance in PostGres appears to start at £21.66 with additional 0.089 per GB so lets say 2gb to start with that puts it £3.6499 vs £21.838 jumping to something like £10.97 vs £43.91 a month when you go to the 250GB equivalents. PostGres hasn't got a direct matching price structure in terms of the DTUs in azure so this might be an incorrect comparison.
On the face of it for individual developers wishing to proceed with a serious serverless product that really only needs to cope with CRUD in the future it looks like SQL server is cheaper.
At the same time I definitely don't want to go full serverless as I like to create and drop databases at short notice for small things. For me the cost is minimal enough that I will chose the database more for the tooling than the cost. I think its good to have Postgres there as its a serious contender constraining the prices of SQL Server. I don't touch Oracle unless I have to.
For individual developers who don't have the knowledge of those in here who mainly do simple view statements and create and drop tables there is almost zero cost to switching in terms of getting up to speed which might be why MS have set their prices as they have.
Their serverless pricing structure certainly doesn't look like its aimed at the serious DBA professional
cloudydatablog.net
November 8, 2018 at 1:25 am
To get around the limitations, one needs to install many instances and many DBs. Cross-server transactions become more difficult. It is altogether more hassle but given that the licence cost for SQL Server is zero, it is a redistribution of resources from cost to time.
November 8, 2018 at 2:11 am
I like the concept of this, the "longer timespan than a lifetime"-approach to solutions and decisions.
I have seen, though, the result of ever changing minds still with the long headlight on.
It is just a bloody waste of everybody's time!
November 8, 2018 at 7:59 am
And here we see once again the dogma of being top of the line for to long of a time. Because there is always someone out there who can do it better, faster and cheaper. Microsoft needs to realize that Big Game companies may be willing to pay their prices but medium to small companies can not and need to have the same DR capabilities if not more than what Microsoft offers based on their business niche. I get that they want to make money, so does everyone else. Microsoft - Stop shooting yourself in the foot. After a while you'll run out of toes. LOL
November 8, 2018 at 8:34 am
Today in 2018, when an IT organization is thinking about the next 5 or 10 years, the debate shouldn't be Standard Edition vs. Enterprise Edition or SQL Server vs. PostgreSQL, they should be thinking about on-prem vs. cloud hosted platform as a service. With Azure; storage, HA, DR and spinning up things like VMs or applications just works.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 9, 2018 at 4:43 am
pbelter - Thursday, November 8, 2018 7:59 AMAnd here we see once again the dogma of being top of the line for to long of a time. Because there is always someone out there who can do it better, faster and cheaper. Microsoft needs to realize that Big Game companies may be willing to pay their prices but medium to small companies can not and need to have the same DR capabilities if not more than what Microsoft offers based on their business niche. I get that they want to make money, so does everyone else. Microsoft - Stop shooting yourself in the foot. After a while you'll run out of toes. LOL
Having worked in the game industry for some of these big companies, I will say that a lot are moving towards open source such as NoSQL to save on costs as dropping millions on say Oracle licenses and so forth. This is mostly because so many of these games are obviously built from scratch with no guarantee it will be successful (i.e.: not proven). Thus, anything to reduce that risk is surely sometime these big companies want to adapt. The issue is, if you're needing a database for a game, you also need something that can support a massive amount of transactions without fear the transaction will be lost or wrong.
November 9, 2018 at 6:50 am
David.Poole - Thursday, January 22, 2015 6:52 AMI've been surprised by the cost of some NOSQL solutions. By the time you do the sizing and capacity piece plus DR the costs can be considerably more than anticipated.The various software editions for any vendor is just a basic way of selling a product for what people are prepared to pay. They can rationalise back based on the additional features that are must haves.Partitioning and compression are particularly useful features.
This is so true. I've been absent from this site for awhile because my last employer decided to move to MongoDB. By the time you consider the hosting costs, licensing and especially the retraining and redesign it's not really as cheap as it first seems. I'm back in a Microsoft shop but last I heard my old employer has decided to go back to SQL...what a waste of time and money.
November 10, 2018 at 3:08 am
Y.B. - Friday, November 9, 2018 6:50 AMDavid.Poole - Thursday, January 22, 2015 6:52 AMI've been surprised by the cost of some NOSQL solutions. By the time you do the sizing and capacity piece plus DR the costs can be considerably more than anticipated.The various software editions for any vendor is just a basic way of selling a product for what people are prepared to pay. They can rationalise back based on the additional features that are must haves.Partitioning and compression are particularly useful features.This is so true. I've been absent from this site for awhile because my last employer decided to move to MongoDB. By the time you consider the hosting costs, licensing and especially the retraining and redesign it's not really as cheap as it first seems. I'm back in a Microsoft shop but last I heard my old employer has decided to go back to SQL...what a waste of time and money.
That's not just a NoSQL thing. Hosting, licensing, redesign are not specific to any one engine. This can happen for SQL Server just as well MongoDB. It's just risky all around to dramatically make a switch no matter what technology you use. This is like blaming NoSQL or even SQL Server for bad design choices made by humans. Has nothing to do with the technology unless the technology forces you to do so.
November 10, 2018 at 7:26 am
Steve Jones - SSC Editor - Monday, February 2, 2015 8:27 AMDavid.Poole (1/31/2015)
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.I think you'd be surprised at this. So many of the DBAs I've known use a GUI, especially when they're trying things out. They find it easier to click to add or remove, and I tend to agree. It's a human things that's easier than typing.However, as you said, you rarely do this. I think that's one reason so many people don't script. They point and click. When they get busy, though, I think that they end up slowing down if they haven't scripted a repeatable process.But most don't. I've watched Oracle DBAs that had 15 years of experience not run a script with a parameter, but rather type the equivalent of "create login xx for yyy" rather than "Createuser.PS1 'Steve@steve.com'"
Like Yogi Berra used to say, "When you come to a fork in the road, take it". 😀 Depending on the task, I use the best of both worlds. Sometimes it's a whole lot faster to do something by GUI so I'll fire up the GUI to make all the selections I want. But I almost never execute from the GUI. Almost without exception, I'll gen the script from the GUI, perhaps make a change or two but not always, then execute the script.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2018 at 10:04 am
Back to the subject of "switching", I've found that there are several hidden costs to making such switches. The single greatest loss (IMHO) is "Lost Learning" and the "art" of "Unlearning what you have learned". There's also the hidden cost of losing experienced people because they simply don't want to have to go through teaching themselves how to do all the nuances of a different RDBMS and whatever features it may or may not have.
SQL<>SQL. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply