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?
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?
- 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?
Was genuinely curious.
[0]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.
Postgres and their org respects you, unlike MSFT.
I mean I'm a big fan of the tech but this seems like a stretch
it's not the case I think
As a 'side effect' of replication, PostgreSQL supports subscribing on change data. What you do with those changes is up to you. There are tools that make it easy to propagate those changes to message queues or other databases.
I totally agree that postgresql offers the foundational bricks that allow easy CDC though
Yeah - cost. :)
Cost is the reason I’m moving everything I can off our existing MSSql Servers before our next renewal comes up in a years time.
We did our due diligence and tested all manner of existing expensive queries and whilst there are a handful we just can’t get to run as fast as MSSql Server on Postgres, they only run slightly longer on average (as in 9 or 10 minutes as opposed to 6 or 7) and only at night.
However, given the cost differential ($50k+ vs $0), we can live with this.
I worked with MSSQLServer 05/08/12 in some projects and the whole suite for the time being was one of the best related in terms of easiness to deploy plus due to the integrations with Integration/Analysis services you could deploy cubes and serving that directly on Excel and if you had some people creative in VBA you could reach a very sophisticated and effective way to provide reports.
I am huge fan of PostgreSQL, but back in 2005/2012 in all organisations that I worked would be very hard to justify 3+ extra FTE because someone was idealistically about Open Source a land costs.
It's a very complicated dimension, especially with databases from vendors that make you go through complicated licensing schemes and audits.
One thing that we need to take into consideration is back in 2005/2012 the ecosystem around the tooling/frameworks and RDBMS was quite fragmented and whether we like it or not, the non-tech industries had their procurements based on corporate vendors.
I was not a decision-maker at that time, but from what I saw, selling Open Source technologies with the addition of FTEs(OPEX) instead of relying on corporate vendors certified by the auditors and having those costs as CAPEX was a very tough sell. On top of that: several folks making hiring decisions back in time, found that it was way simpler to recruit people to work on SQLServer in a less plug&play stack integrated instead of doing a Jenga stack with several technologies that did not talk to each other and inject FTEs on.
Today the Open Source technologies are way more mature (I dare to say largely better) than those of corporate vendors.
I mean, I am sure there are companies with site licenses and it is easy to stand up a new microsoft stack, but I have never worked at any of them, for us it was always fighting with management and the purchasing department to get the licenses we needed. As none of us were really people persons this is exhausting. It was so much easier to stand up a service on linux in comparison. No bureaucracy, no delays just get it and go. So we pushed very hard into the linux and friends stack.
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).
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.
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.
However, assuming a non-cloud environment (on-prem), SQL Server Standard on a powerful server can go a very long way for about $7-10K in one-time licensing cost. This also buys you product support, which doesn't exist for free for PG.
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.
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.