5 ms·

I hear this often with regards to Postgre. Can't all of the above be said about Microsoft SQL Server as well? What prevents SQL Server from being used in the

by ijidak 3y ago

I hear this often with regards to Postgre. Can't all of the above be said about Microsoft SQL Server as well? What prevents SQL Server from being used in the same cases you mention above?

leosanchez 3y ago
Licensing cost ?
- kstrauser 3y ago
  Yep. I can use PostgreSQL anywhere I want, for any purpose I want, in any configuration I want, for free. That means I can use one stack from the tiniest of projects up through giant production systems, and also that I never have to wait for budget approval before scaling or launching new staging environments or spinning up a thousand test instances. For me, the onus is on any other DB to convince me that I should use it instead of PostgreSQL. The few times when that's been the case, it's been because we needed something other than a relational database for various specific reasons. At this point I can't think of many reasons I'd use anything else than psql that's in the same category. Like, I can imagine requirements that would send me to Snowflake or Redis or DynamoDB much more easily than things that would nudge me to SQL Server or even MariaDB.
  - AtlasBarfed 3y ago
    What proprietary databases (and the Lord's of data fiefdoms in large enterprises that control them) fail in IT isn't necessarily production stability and performance. It's the ridiculous hoops you have to jump through to spin up a development insurance, a qa/unit test instance, to integrate with build pipelines, to run locally or in the cloud. If you're trying to diagnose something really hard, like intransigent performance or debugging issues , and you need to spin up a near copy of production to run big tests, well have fun getting that by your license sever or the license audit.
datavirtue 3y ago
Eye watering licensing costs. A small company I was at increased the number of cores on the SQL Server VMs, the CFO pissed off and fired a few DBAs, Microsoft audit ensues, and we had to find an extra $1MM in the budget for SQL Server licensing.
wiredfool 3y ago
Licensing per core makes it difficult to really take over the world.
FridgeSeal 3y ago
- cost - only recently runs on Linux - cost - all sorts of MSSQL specific features and syntax (@@ is unhinged and you can’t convince me otherwise) - Postgres docs are better - Postgres has a massive ecosystem of extensions (see PostGIS alone!) - did I mention the cost? - Postgres has wider range language support: basically every language I’ve ever used has a PG library. Not the case for MSSQL. Additionally some of the MSSQL libs are real bad, the Python one is basically like “use this ancient odbc lib lol” it’s great from .net and awful from everywhere else. - licensing and running costs, because these cannot be overstated. - features like CDC locked behind _expensive_ licenses, that you get out of the box with Postgres. Need I say more?
- ijidak 3y ago
  Got it. Appreciate that. That makes sense. Was genuinely curious.
  - willcipriano 3y ago
    On the cost front do you still need a cal[0] for every user/device? [0]https://www.trustedtechteam.com/collections/microsoft-sql-server-cals https://www.trustedtechteam.com/collections/microsoft-sql-se...
    - kstrauser 3y ago
      From https://www.trustedtechteam.com/collections/microsoft-sql-server-cals https://www.trustedtechteam.com/collections/microsoft-sql-se... > CALs offer businesses the flexibility to scale their client access as needed, accommodating a varying number of users or devices accessing SQL Server. The gall required to write that sentence is astonishing.
  - mixmastamyk 3y ago
    Buried one of the most important reasons—FLOSS. Postgres and their org respects you, unlike MSFT.
- VeejayRampay 3y ago
marcosdumay 3y ago
> Can't all of the above be said about Microsoft SQL Server as well? No. MS SQL doesn't just keep working, needs real hardware to run, doesn't handle noSql work anywhere as well, and has many small bugs that pop-up here or there. Besides, it's a quite visible expense - that would be ok if it gained you anything. And just as impacting but on a different dimension, it requires much more query optimization, and its language is just awful when compared to Postgres (even though it's probably the next best thing out there).
- briHass 3y ago
  Pure nonsense, except for the licensing cost comment. SQL Server has arguably the best query planner/optimizer in the RDBMS space, and it also has tons of management tools and simple integrations in a Windows environment (tight AD integration) that admin very easy. If cost were no object and you need a DB that requires essentially zero babysitting after the initial setup, SQL Server is a better choice than PG. TSQL takes some getting used to, but it allows for powerful/flexible stored procedures that can replace the vast majority of external business logic (for better or worse, depending on the application architecture.) That said, PG is definitely more flexible with things like custom types and all the extensions you can add, and SQL Server's better query/clustered index performance isn't likely to make a huge difference in most workloads. The cost of SQL Server is also outrageous, especially run on large (CPU) instances. PG is usually a better choice for cost alone, but SQL Server is not an inferior DB by any means.
  - AtlasBarfed 3y ago
    Saying a proprietary database works well with a proprietary operating system is not a feature in the age of IaC and the cloud. I understand there are still loads of enterprises stuck in the windows zone, but ... It's not ideal. As for query performance, I doubt it id that significant... Well, unless you are constrained by a proprietary db license and approved CPU count / machine size and need to squeeze more from less. Because if you are on postgres and are bumping into hardware limits, a slightly better query planner is a very short term bandaid. At that point, you are likely a year past the point where you should take your biggest queries and refactor/architect scale them to dynamo or Cassandra or something like that. I mean, bragging about active directory integration in 2024. It should be a dumb LDAP / identity provider,not some chain bonding you to Microsoft software in perpetuity.

by ijidak 3y ago

I hear this often with regards to Postgre. Can't all of the above be said about Microsoft SQL Server as well? What prevents SQL Server from being used in the same cases you mention above?

leosanchez 3y ago

Licensing cost ?

kstrauser 3y ago
Yep. I can use PostgreSQL anywhere I want, for any purpose I want, in any configuration I want, for free. That means I can use one stack from the tiniest of projects up through giant production systems, and also that I never have to wait for budget approval before scaling or launching new staging environments or spinning up a thousand test instances. For me, the onus is on any other DB to convince me that I should use it instead of PostgreSQL. The few times when that's been the case, it's been because we needed something other than a relational database for various specific reasons. At this point I can't think of many reasons I'd use anything else than psql that's in the same category. Like, I can imagine requirements that would send me to Snowflake or Redis or DynamoDB much more easily than things that would nudge me to SQL Server or even MariaDB.
- AtlasBarfed 3y ago
  What proprietary databases (and the Lord's of data fiefdoms in large enterprises that control them) fail in IT isn't necessarily production stability and performance. It's the ridiculous hoops you have to jump through to spin up a development insurance, a qa/unit test instance, to integrate with build pipelines, to run locally or in the cloud. If you're trying to diagnose something really hard, like intransigent performance or debugging issues , and you need to spin up a near copy of production to run big tests, well have fun getting that by your license sever or the license audit.

datavirtue 3y ago

Eye watering licensing costs. A small company I was at increased the number of cores on the SQL Server VMs, the CFO pissed off and fired a few DBAs, Microsoft audit ensues, and we had to find an extra $1MM in the budget for SQL Server licensing.

wiredfool 3y ago

Licensing per core makes it difficult to really take over the world.

FridgeSeal 3y ago

- cost - only recently runs on Linux - cost - all sorts of MSSQL specific features and syntax (@@ is unhinged and you can’t convince me otherwise) - Postgres docs are better - Postgres has a massive ecosystem of extensions (see PostGIS alone!) - did I mention the cost? - Postgres has wider range language support: basically every language I’ve ever used has a PG library. Not the case for MSSQL. Additionally some of the MSSQL libs are real bad, the Python one is basically like “use this ancient odbc lib lol” it’s great from .net and awful from everywhere else. - licensing and running costs, because these cannot be overstated. - features like CDC locked behind _expensive_ licenses, that you get out of the box with Postgres. Need I say more?

ijidak 3y ago
Got it. Appreciate that. That makes sense. Was genuinely curious.
- willcipriano 3y ago
  On the cost front do you still need a cal[0] for every user/device? [0]https://www.trustedtechteam.com/collections/microsoft-sql-server-cals https://www.trustedtechteam.com/collections/microsoft-sql-se...
  - kstrauser 3y ago
    From https://www.trustedtechteam.com/collections/microsoft-sql-server-cals https://www.trustedtechteam.com/collections/microsoft-sql-se... > CALs offer businesses the flexibility to scale their client access as needed, accommodating a varying number of users or devices accessing SQL Server. The gall required to write that sentence is astonishing.
- mixmastamyk 3y ago
  Buried one of the most important reasons—FLOSS. Postgres and their org respects you, unlike MSFT.
VeejayRampay 3y ago

marcosdumay 3y ago

> Can't all of the above be said about Microsoft SQL Server as well? No. MS SQL doesn't just keep working, needs real hardware to run, doesn't handle noSql work anywhere as well, and has many small bugs that pop-up here or there. Besides, it's a quite visible expense - that would be ok if it gained you anything. And just as impacting but on a different dimension, it requires much more query optimization, and its language is just awful when compared to Postgres (even though it's probably the next best thing out there).

briHass 3y ago
Pure nonsense, except for the licensing cost comment. SQL Server has arguably the best query planner/optimizer in the RDBMS space, and it also has tons of management tools and simple integrations in a Windows environment (tight AD integration) that admin very easy. If cost were no object and you need a DB that requires essentially zero babysitting after the initial setup, SQL Server is a better choice than PG. TSQL takes some getting used to, but it allows for powerful/flexible stored procedures that can replace the vast majority of external business logic (for better or worse, depending on the application architecture.) That said, PG is definitely more flexible with things like custom types and all the extensions you can add, and SQL Server's better query/clustered index performance isn't likely to make a huge difference in most workloads. The cost of SQL Server is also outrageous, especially run on large (CPU) instances. PG is usually a better choice for cost alone, but SQL Server is not an inferior DB by any means.
- AtlasBarfed 3y ago
  Saying a proprietary database works well with a proprietary operating system is not a feature in the age of IaC and the cloud. I understand there are still loads of enterprises stuck in the windows zone, but ... It's not ideal. As for query performance, I doubt it id that significant... Well, unless you are constrained by a proprietary db license and approved CPU count / machine size and need to squeeze more from less. Because if you are on postgres and are bumping into hardware limits, a slightly better query planner is a very short term bandaid. At that point, you are likely a year past the point where you should take your biggest queries and refactor/architect scale them to dynamo or Cassandra or something like that. I mean, bragging about active directory integration in 2024. It should be a dumb LDAP / identity provider,not some chain bonding you to Microsoft software in perpetuity.