6 ms·

Always has been. I've been using PostgreSQL for a decades, and I feel so spoiled. It always Just Works. Not to say there've never been bugs, but compared to an

Always has been. I've been using PostgreSQL for a decades, and I feel so spoiled. It always Just Works. Not to say there've never been bugs, but compared to anything else with that much surface area, it's a brilliant piece of engineering. It's astonishing how often it's a perfectly fine stand-in for the "right" solution. Need a K-V store to hold a bunch of JSON docs indexed by UUID? Fine. Want to make an append-only log DB? Why not. Should you do those things? Probably not, but unless you specifically need to architect for global-scale concurrent usage, it's likely to work out just fine. For me, it's the default place to stick data unless I have a specific requirement that only something else can meet. I've never once regretted using it to launch a production system, and only a couple of times have needed to migrate off of it due to performance demands. Thanks, PostgreSQL team! You rock.

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.
CharlesW 3y ago
> Always has been. It definitely has not always been. https://www.quora.com/Why-is-MySQL-more-popular-than-PostgreSQL https://www.quora.com/Why-is-MySQL-more-popular-than-Postgre... (2010)
- tomnipotent 3y ago
  Postgres wasn't even on my radar until the 9.1 release (2011) rounded out their replication story. MySQL replication had been baking for a decade at that point, despite its other glaring flaws.
  - SOLAR_FIELDS 3y ago
    Yeah, in my personal anecdotal experience Postgres wasn’t really known as the “good enough for anything, rarely the best at anything but pretty good at it” workhorse until the mid 2010’s. It is great though, amazing piece of technology. Not 100% sure you need some specialized data store for your use case? (Most people aren’t). Pick Postgres. You can always switch to SpecializedDB later when pg falls over. I cannot undersell enough how hard it is to be at being 90% good at everything. Like, you can pick Postgres for these technologies and not get fired for it at first glance and it will carry you to medium-large scale - time series - GIS - Graph - CRUD/ Jamstack apps (eg Supabase) - Queues - and on and on and on If it even tangentially involves data you can trust that Postgres has some solution that will mostly work with some edge cases unless you are at disgusting levels of scale. Love it. A true jack of all trades
- ttfkam 3y ago
  Even today, Postgres on Windows isn't a viable target for performance reasons. Postgres is one process per connection. Spawning processes on Windows is slow compared to Unix. Building/running Postgres in Windows' Linux compatibility layer or within Docker is typically the better option, especially considering that every cloud vender offers Postgres running on a Linux OS, and it's best to have your dev environment match your deployment environment as closely as possible. With Linux as your starting point, getting up and running with apt-get install mysql vs. apt-get install postgresql was trivially similar in 2010.
BeefWellington 3y ago
I would caveat the "Just Works" thing for your specific use-cases. I've seen plenty where PG's query planner falls apart and requires copious coaxing beyond what Oracle, DB2, and MSSQL require in order to do the performant thing. It's a fantastic product and I use it everywhere. My major complaint is that there's no easy way to follow defect statuses because the team has long stubbornly refused to implement a bug tracker[1] and that means I can't just subscribe to a defect to get status updates for an issue I want to watch. Instead I'm expected to follow the entire mailing list or watch changelogs like a hawk. It's incredibly dumb. [1]: https://www.postgresql.org/docs/current/bug-reporting.html#BUG-REPORTING-WHERE-TO-REPORT-BUGS https://www.postgresql.org/docs/current/bug-reporting.html#B...

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.

CharlesW 3y ago

> Always has been. It definitely has not always been. https://www.quora.com/Why-is-MySQL-more-popular-than-PostgreSQL https://www.quora.com/Why-is-MySQL-more-popular-than-Postgre... (2010)

tomnipotent 3y ago
Postgres wasn't even on my radar until the 9.1 release (2011) rounded out their replication story. MySQL replication had been baking for a decade at that point, despite its other glaring flaws.
- SOLAR_FIELDS 3y ago
  Yeah, in my personal anecdotal experience Postgres wasn’t really known as the “good enough for anything, rarely the best at anything but pretty good at it” workhorse until the mid 2010’s. It is great though, amazing piece of technology. Not 100% sure you need some specialized data store for your use case? (Most people aren’t). Pick Postgres. You can always switch to SpecializedDB later when pg falls over. I cannot undersell enough how hard it is to be at being 90% good at everything. Like, you can pick Postgres for these technologies and not get fired for it at first glance and it will carry you to medium-large scale - time series - GIS - Graph - CRUD/ Jamstack apps (eg Supabase) - Queues - and on and on and on If it even tangentially involves data you can trust that Postgres has some solution that will mostly work with some edge cases unless you are at disgusting levels of scale. Love it. A true jack of all trades
ttfkam 3y ago
Even today, Postgres on Windows isn't a viable target for performance reasons. Postgres is one process per connection. Spawning processes on Windows is slow compared to Unix. Building/running Postgres in Windows' Linux compatibility layer or within Docker is typically the better option, especially considering that every cloud vender offers Postgres running on a Linux OS, and it's best to have your dev environment match your deployment environment as closely as possible. With Linux as your starting point, getting up and running with apt-get install mysql vs. apt-get install postgresql was trivially similar in 2010.

BeefWellington 3y ago

I would caveat the "Just Works" thing for your specific use-cases. I've seen plenty where PG's query planner falls apart and requires copious coaxing beyond what Oracle, DB2, and MSSQL require in order to do the performant thing. It's a fantastic product and I use it everywhere. My major complaint is that there's no easy way to follow defect statuses because the team has long stubbornly refused to implement a bug tracker[1] and that means I can't just subscribe to a defect to get status updates for an issue I want to watch. Instead I'm expected to follow the entire mailing list or watch changelogs like a hawk. It's incredibly dumb. [1]: https://www.postgresql.org/docs/current/bug-reporting.html#BUG-REPORTING-WHERE-TO-REPORT-BUGS https://www.postgresql.org/docs/current/bug-reporting.html#B...