4 ms·

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed en

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work well for workloads it wasn’t designed for, at even reasonable scale. At Citus Data, we saw many customers with solid-sized teams of Postgres experts whose primary job was constant tuning, operating, and essentially babysitting the system to keep it performing at scale. Side note, we’re seeing purpose-built technologies show up much earlier in a company’s lifecycle, likely accelerated by AI-driven use cases. At ClickHouse, many customers using Postgres replication are seed-stage companies that have grown extremely quickly. We pulled together some data on these trends here: https://clickhouse.com/blog/postgres-cdc-year-in-review-2025#use-cases https://clickhouse.com/blog/postgres-cdc-year-in-review-2025... A better approach would be to embrace the integration of purpose-built technologies with Postgres, making it easier for users to get the best of both worlds, rather than making overgeneralized claims like “Postgres for everything” or “Just use Postgres.”

pimlottc 9mo ago
I took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”
- saisrirampur 9mo ago
  I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO a better world is one where developers can have a mindset of using best-in-class where needed. This is where embracing integrations with Postgres will be helpful!
  - PunchyHamster 9mo ago
    The point is really that you can only evaluate which of alternatives is better once you have working product with data big enough - else it's just basically following trends and hoping your barely informed decision won't be wrong.
    - saisrirampur 9mo ago
      Agree to disagree here. I see a world where developers need to think about (reasonable) scale from day one, or at least very early. We’ve been seeing this play out at ClickHouse - the need for purpose-built OLAP is reducing from years to months. Also integration with ClickHouse is few weeks of effort for potentially significantly faster performance for analytics.
      - hermanzegerman 9mo ago
        [flagged]
        saisrirampur 9mo ago
        That wasn’t my intention though to mention my workplace multiple times for the sake of PR. Try to avoid being that, atleast on hn. :)
        daotoad 9mo ago
        What I really want to know is, is it mighty mighty? And does it let it all hang out?
        direwolf20 9mo ago
        Unless you have YC funding. Conflicts of interest go brrr! HN doesn't even try to hide it.
        tomhow 9mo ago
- SOLAR_FIELDS 9mo ago
  This is my philosophy. When the engineer comes to me and says that they want to use NotPostgres, they have to justify why, with data and benchmarks, Postgres is not good enough. And that’s how it should be
- jimbokun 9mo ago
  This could be similar to defaulting to a monolith service, and breaking it into micro services only when experience demands it. Start with Postgres for everything, then use custom solutions where you are running into the limitations of Postgres.
cheriot 9mo ago
> I don’t agree with the blanket advice of “just use Postgres.” I take it as meaning use Postgres until there's a reason not to. ie build for the scale / growth rate you have not "how will this handle the 100 million users I dream of." A simpler tech stack will be simpler to iterate on.
- quotemstr 9mo ago
  Yes. That's a good framing. PostgreSQL is a good default for online LOB-y things. There are all sorts of reasons to use something other than PostgreSQL, but raw performance at scale becomes such a reason later than you think. Cloud providers will rent you enormous beasts of machines that, while expensive, will remain cheaper than rewriting for a migration for a long time.
- pclmulqdq 9mo ago
  Postgres on modern hardware can likely service 100 million users unless you are doing something data intensive with them. You can get a few hundred TB of flash in one box these days. You need to average over 1 MB of database data per user to get over 100 TB with only 100 million users. Even then, you can mostly just shard your DB.
  - direwolf20 9mo ago
    What about throughput? How many times can postgres commit per second on NVMe flash?
    - pclmulqdq 9mo ago
      You can do about 100k commits per second, but this also partly depends on the CPU you attach to it. It also varies with how complicated the queries are. With 100 million DAU, you're often going to have problems with this rate unless you batch your commits. With 100 million user accounts (or MAU), you may be fine.
      - direwolf20 9mo ago
LaGrange 9mo ago
> At Citus Data, we saw many customers with solid-sized teams of Postgres experts whose primary job was constant tuning, operating, and essentially babysitting the system to keep it performing at scale. Oh no, not a company hiring a team of specialist in a core technology you need! What next, paying them a good wage? C'mon, it's so much better to get a bunch of random, excuse me, "specialized" SaaS tools that will _surely_ not lead to requiring five teams of specialists in random technologies that will eventually be discontinued once Google acquires the company running them. OK but seriously, yeah sometimes "specialized" is good, though much less rarely than people pretend it to be. Having specialists ain't bad, and I'd say is better than telling a random developer to become a specialist in some cloud tech and pretending you didn't just end up turning a - hopefully decent - developer into a poor DBA. Not to mention that a small team of Postgres specialists can maintain a truly stupendous amount of Postgres.
- bloaf 9mo ago
  At my company I saw a team of devs pay for a special purpose "query optimized" database with "exabyte capability" to handle... their totally ordinary HR data. I queried said database... it was slow. I looked to see what indexes they had set up... there were none. That team should have just used postgres and spent all the time and money they poured into this fancy database tech on finding someone who knew even a little bit about database design to help them.
Fairburn 9mo ago
Exactly. Use cases differ. https://www.geeksforgeeks.org/mysql/difference-between-mysql-and-postgresql/ https://www.geeksforgeeks.org/mysql/difference-between-mysql...
- Dan42 9mo ago
  That article was clearly written by AI, based on data from 20 years ago.
groundzeros2015 9mo ago
In my experience the functionality of “purpose built systems” is found in Postgres but you have to read the manual. I personally think reading manuals and tuning is a comparably low risk form of software development.
jongjong 9mo ago
I hate how developers are often very skeptical but all the skepticism goes out the window if the tech is sufficiently hyped up. And TBH, developers are pretty dumb not to realize that the tech tools monoculture is a way for business folks to make us easily replaceable... If all companies use the same tech, it turns us into exchangeable commodities which can easily be replaced and sourced across different organizations. Look at the typical React dev. They have zero leverage and can be replaced by vibe coding kiddies straight out of school or sourced from literally any company on earth. And there are some real negatives to using silver bullet tools. They're not even the best tools for a lot of cases! The React dev is a commodity and they let it happen to them. Outsmarted by dumb business folks who dropped out of college. They probably didn't even come up with the idea; the devs did. Be smarter people. They're going to be harvesting you like Cavendish.
- pimlottc 9mo ago
  Sure, but the world is vast. I would love to be able to test every UI framework and figure out which is the best, but who’s got time for that? You have to rely on heuristics for some things, and popularity is often a decent indicator.
  - mattgreenrocks 9mo ago
    Popularity’s flip side is that it can fuel commodification. I argue popularity is insufficient signal. React as tech is fine, but the market of devs who it is aimed at may not be the most discerning when it comes to quality.
- jakubmazanec 9mo ago
  > Look at the typical React dev. They have zero leverage and can be replaced by vibe coding kiddies straight out of school or sourced from literally any company on earth. Good luck maintaining such code. As we know from constant whining here on HN ("Hooks are too complicated..." "I don't understand useEffect"), React's model feels slightly more complex than other frameworks' models. I can even argue that the more popular React is, the more React developers are needed.
direwolf20 9mo ago
Postgres is infinitely extensible, more than MariaDB. But it's very painful to write or configure extensions and you might as well use something different instead of reaching for an extension mechanism.
Sparkyte 8mo ago
My opinion use the database that is the most compatible with the software you are currently using. Don't shoehorn in a database that is less compatible.
meng-lin-maker 8mo ago
Since Postgres is usually a good starting point and it's much easier to work with the same technologies. Which could lead to Postgres being pushed to weird limits later on. Using new technology is probably too risky unless Postgres is not capable
meng-lin-maker 8mo ago
But I do think there's so much marketing out there too. So it's difficult to trust certain technologies until it has been proven.

pimlottc 9mo ago

I took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”

saisrirampur 9mo ago
I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO a better world is one where developers can have a mindset of using best-in-class where needed. This is where embracing integrations with Postgres will be helpful!
- PunchyHamster 9mo ago
  The point is really that you can only evaluate which of alternatives is better once you have working product with data big enough - else it's just basically following trends and hoping your barely informed decision won't be wrong.
  - saisrirampur 9mo ago
    Agree to disagree here. I see a world where developers need to think about (reasonable) scale from day one, or at least very early. We’ve been seeing this play out at ClickHouse - the need for purpose-built OLAP is reducing from years to months. Also integration with ClickHouse is few weeks of effort for potentially significantly faster performance for analytics.
    - hermanzegerman 9mo ago
      [flagged]
      - saisrirampur 9mo ago
        That wasn’t my intention though to mention my workplace multiple times for the sake of PR. Try to avoid being that, atleast on hn. :)
        daotoad 9mo ago
        What I really want to know is, is it mighty mighty? And does it let it all hang out?
        direwolf20 9mo ago
        Unless you have YC funding. Conflicts of interest go brrr! HN doesn't even try to hide it.
        tomhow 9mo ago
SOLAR_FIELDS 9mo ago
This is my philosophy. When the engineer comes to me and says that they want to use NotPostgres, they have to justify why, with data and benchmarks, Postgres is not good enough. And that’s how it should be
jimbokun 9mo ago
This could be similar to defaulting to a monolith service, and breaking it into micro services only when experience demands it. Start with Postgres for everything, then use custom solutions where you are running into the limitations of Postgres.

cheriot 9mo ago

> I don’t agree with the blanket advice of “just use Postgres.” I take it as meaning use Postgres until there's a reason not to. ie build for the scale / growth rate you have not "how will this handle the 100 million users I dream of." A simpler tech stack will be simpler to iterate on.

quotemstr 9mo ago
Yes. That's a good framing. PostgreSQL is a good default for online LOB-y things. There are all sorts of reasons to use something other than PostgreSQL, but raw performance at scale becomes such a reason later than you think. Cloud providers will rent you enormous beasts of machines that, while expensive, will remain cheaper than rewriting for a migration for a long time.
pclmulqdq 9mo ago
Postgres on modern hardware can likely service 100 million users unless you are doing something data intensive with them. You can get a few hundred TB of flash in one box these days. You need to average over 1 MB of database data per user to get over 100 TB with only 100 million users. Even then, you can mostly just shard your DB.
- direwolf20 9mo ago
  What about throughput? How many times can postgres commit per second on NVMe flash?
  - pclmulqdq 9mo ago
    You can do about 100k commits per second, but this also partly depends on the CPU you attach to it. It also varies with how complicated the queries are. With 100 million DAU, you're often going to have problems with this rate unless you batch your commits. With 100 million user accounts (or MAU), you may be fine.
    - direwolf20 9mo ago

LaGrange 9mo ago

> At Citus Data, we saw many customers with solid-sized teams of Postgres experts whose primary job was constant tuning, operating, and essentially babysitting the system to keep it performing at scale. Oh no, not a company hiring a team of specialist in a core technology you need! What next, paying them a good wage? C'mon, it's so much better to get a bunch of random, excuse me, "specialized" SaaS tools that will _surely_ not lead to requiring five teams of specialists in random technologies that will eventually be discontinued once Google acquires the company running them. OK but seriously, yeah sometimes "specialized" is good, though much less rarely than people pretend it to be. Having specialists ain't bad, and I'd say is better than telling a random developer to become a specialist in some cloud tech and pretending you didn't just end up turning a - hopefully decent - developer into a poor DBA. Not to mention that a small team of Postgres specialists can maintain a truly stupendous amount of Postgres.

bloaf 9mo ago
At my company I saw a team of devs pay for a special purpose "query optimized" database with "exabyte capability" to handle... their totally ordinary HR data. I queried said database... it was slow. I looked to see what indexes they had set up... there were none. That team should have just used postgres and spent all the time and money they poured into this fancy database tech on finding someone who knew even a little bit about database design to help them.

Fairburn 9mo ago

Exactly. Use cases differ. https://www.geeksforgeeks.org/mysql/difference-between-mysql-and-postgresql/ https://www.geeksforgeeks.org/mysql/difference-between-mysql...

Dan42 9mo ago
That article was clearly written by AI, based on data from 20 years ago.

groundzeros2015 9mo ago

In my experience the functionality of “purpose built systems” is found in Postgres but you have to read the manual. I personally think reading manuals and tuning is a comparably low risk form of software development.

jongjong 9mo ago

I hate how developers are often very skeptical but all the skepticism goes out the window if the tech is sufficiently hyped up. And TBH, developers are pretty dumb not to realize that the tech tools monoculture is a way for business folks to make us easily replaceable... If all companies use the same tech, it turns us into exchangeable commodities which can easily be replaced and sourced across different organizations. Look at the typical React dev. They have zero leverage and can be replaced by vibe coding kiddies straight out of school or sourced from literally any company on earth. And there are some real negatives to using silver bullet tools. They're not even the best tools for a lot of cases! The React dev is a commodity and they let it happen to them. Outsmarted by dumb business folks who dropped out of college. They probably didn't even come up with the idea; the devs did. Be smarter people. They're going to be harvesting you like Cavendish.

pimlottc 9mo ago
Sure, but the world is vast. I would love to be able to test every UI framework and figure out which is the best, but who’s got time for that? You have to rely on heuristics for some things, and popularity is often a decent indicator.
- mattgreenrocks 9mo ago
  Popularity’s flip side is that it can fuel commodification. I argue popularity is insufficient signal. React as tech is fine, but the market of devs who it is aimed at may not be the most discerning when it comes to quality.
jakubmazanec 9mo ago
> Look at the typical React dev. They have zero leverage and can be replaced by vibe coding kiddies straight out of school or sourced from literally any company on earth. Good luck maintaining such code. As we know from constant whining here on HN ("Hooks are too complicated..." "I don't understand useEffect"), React's model feels slightly more complex than other frameworks' models. I can even argue that the more popular React is, the more React developers are needed.

direwolf20 9mo ago

Postgres is infinitely extensible, more than MariaDB. But it's very painful to write or configure extensions and you might as well use something different instead of reaching for an extension mechanism.

Sparkyte 8mo ago

My opinion use the database that is the most compatible with the software you are currently using. Don't shoehorn in a database that is less compatible.

meng-lin-maker 8mo ago

Since Postgres is usually a good starting point and it's much easier to work with the same technologies. Which could lead to Postgres being pushed to weird limits later on. Using new technology is probably too risky unless Postgres is not capable

meng-lin-maker 8mo ago

But I do think there's so much marketing out there too. So it's difficult to trust certain technologies until it has been proven.