4 ms·

Just use the right tool for the job at hand. If it’s Postgres for now, sure. There’s really nothing more to this. Period. But saying this would not make for a

Just use the right tool for the job at hand. If it’s Postgres for now, sure. There’s really nothing more to this. Period. But saying this would not make for a blog post. I can’t help but categorize this post as juvenile at best. Generalizations like “use XXX for everything’ should be avoided at all costs. No software product serves well to such sweeping generalizations. I’m surprised that it’s coming from a CTO. They should know better if they’re worth their salt .

simonw 4y ago
It's often better to use the tool that is capable but isn't the absolute best possible option to solve multiple problems, rather than taking on the burden of running five different "best" tools for five different problems.
- cortesoft 4y ago
  If you are at a startup, sure. But many of us work at big companies that have the scale that requires specialized solutions. I just frustrated that everyone always seems to assume everyone is working on POCs at startups.
  - necovek 4y ago
    Somebody just jumping on a new tool thinking it's the right tool for the job might still end up with worse performance than someone proficient with another tool (like Postgres) might get in less time. No matter the scale or how big it is. If you are talking of specialized solutions, that means you know exactly where an existing, well known solution is failing you and why. Eg. if you drop all foreign key references and constraints in Postgres, you might get similar write performance to other databases which can't make those guarantees when you do need them.
  - simonw 4y ago
    I've worked at big companies, where I have championed introducing "the right" technology for scale reasons... and have in some cases later regretted it because with hindsight we would have been fine sticking with what we had already, at a greatly reduced cost in terms of time and complexity.
fbdab103 4y ago
Engineering is trade-offs. Complexity is an enormous one best avoided unless you absolutely cannot work with the simpler system.
New_California 4y ago
> Just use the right tool for the job at hand. Period. That's Postgres.
deleted 4y ago
[deleted]
KingOfCoders 4y ago
It comes from a CTO (me ;-) coach who has seen dozens of startups entangle themselves with systems until they work more on tech than on delivering features - or who came to a standstill after VC driven layoffs b/c of complexity of their systems. "Just use the right tool for the job at hand." Yes, but I have heard exact that phrase for decades to rationalize tech decisions for tools that weren't needed. I know you're different, but think of all the people who have the same problems. If you need complexity b/c you're Netflix or Uber, go ahead. If you're the 95% others who don't need that complexity, then don't do it. "I can’t help but categorize this post as juvenile at best." Thanks, I guess this is the nicest thing to say to someone 50+!
- tasuki 4y ago
  > Thanks, I guess this is the nicest thing to say to someone 50+! Your username is also juvenile, well done you! Fwiw, my experience has also led me to be on the side of "just use Postgres" unless required otherwise. I've seen enough people glue whatever crazy technologies together where a relational database would've been enough.
  - KingOfCoders 4y ago
    "Your username is also juvenile, well done you!" It was Codemonkeyism before (𝅘𝅥𝅮 "Code Monkey think maybe manager want to write god d** login page himself") but I thought I had grown to be king of the asylum.
deleted 4y ago
[deleted]
necovek 4y ago
"Right tool for the job" is as foolish as any other approach: this discounts the experience someone or even a team might have with another tool that is not a perfect fit, but might still do the job just as well. If you ignore this and instead go with a different tool for every little thing, your project will be a dependency nightmare no developer can master easily. Postgres is an all-purpose database that has it all: relational databases were created to model real world problems, and while they might not perform best for all the usecases, they can usually model them just fine while protecting from many programming errors. And then Postgres has features on top: partial indexes, object DB features, replication etc.

simonw 4y ago

It's often better to use the tool that is capable but isn't the absolute best possible option to solve multiple problems, rather than taking on the burden of running five different "best" tools for five different problems.

cortesoft 4y ago
If you are at a startup, sure. But many of us work at big companies that have the scale that requires specialized solutions. I just frustrated that everyone always seems to assume everyone is working on POCs at startups.
- necovek 4y ago
  Somebody just jumping on a new tool thinking it's the right tool for the job might still end up with worse performance than someone proficient with another tool (like Postgres) might get in less time. No matter the scale or how big it is. If you are talking of specialized solutions, that means you know exactly where an existing, well known solution is failing you and why. Eg. if you drop all foreign key references and constraints in Postgres, you might get similar write performance to other databases which can't make those guarantees when you do need them.
- simonw 4y ago
  I've worked at big companies, where I have championed introducing "the right" technology for scale reasons... and have in some cases later regretted it because with hindsight we would have been fine sticking with what we had already, at a greatly reduced cost in terms of time and complexity.

fbdab103 4y ago

Engineering is trade-offs. Complexity is an enormous one best avoided unless you absolutely cannot work with the simpler system.

New_California 4y ago

> Just use the right tool for the job at hand. Period. That's Postgres.

deleted 4y ago

[deleted]

KingOfCoders 4y ago

It comes from a CTO (me ;-) coach who has seen dozens of startups entangle themselves with systems until they work more on tech than on delivering features - or who came to a standstill after VC driven layoffs b/c of complexity of their systems. "Just use the right tool for the job at hand." Yes, but I have heard exact that phrase for decades to rationalize tech decisions for tools that weren't needed. I know you're different, but think of all the people who have the same problems. If you need complexity b/c you're Netflix or Uber, go ahead. If you're the 95% others who don't need that complexity, then don't do it. "I can’t help but categorize this post as juvenile at best." Thanks, I guess this is the nicest thing to say to someone 50+!

tasuki 4y ago
> Thanks, I guess this is the nicest thing to say to someone 50+! Your username is also juvenile, well done you! Fwiw, my experience has also led me to be on the side of "just use Postgres" unless required otherwise. I've seen enough people glue whatever crazy technologies together where a relational database would've been enough.
- KingOfCoders 4y ago
  "Your username is also juvenile, well done you!" It was Codemonkeyism before (𝅘𝅥𝅮 "Code Monkey think maybe manager want to write god d** login page himself") but I thought I had grown to be king of the asylum.

deleted 4y ago

[deleted]

necovek 4y ago

"Right tool for the job" is as foolish as any other approach: this discounts the experience someone or even a team might have with another tool that is not a perfect fit, but might still do the job just as well. If you ignore this and instead go with a different tool for every little thing, your project will be a dependency nightmare no developer can master easily. Postgres is an all-purpose database that has it all: relational databases were created to model real world problems, and while they might not perform best for all the usecases, they can usually model them just fine while protecting from many programming errors. And then Postgres has features on top: partial indexes, object DB features, replication etc.