Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I don't understand the desire for all-in-one solutions

You really don't understand it? It's less moving pieces to think about, worry about, read about, deploy, maintain, fix and almost always leads to better performance and security.

Something as simple as connection pooling should've already been part of the database and query redirection is even more important to have included.



Is it actually less moving pieces? The sum seems about the same. Your statement seems like FUD.

The unix philosophy of focusing on a single problem and solving it well seems to do just fine. I don't see why baking in featuress that the vast majority of users will never need is a good investment. If anything, it seems like it will only increase the complexity of postgresql. The protocol is well documented and open. Libpq provides all the functionality necessary. Why not bake the higher order logic into a discrete component?


That philosophy is just that - a philosophy that sounds nice and applies sometimes. It's not a rule.

The deployment and upkeep of components is a major hassle and yes, having it all bundled into the same running application (which is the only thing it can be used with anyway) decreases the amount of stuff the end-user has to worry about.

Scaling connections reasonably is something basic any database should handle natively - or better put hitting connection limits without yet another program to help is rather silly in 2017.

You can make the same argument about replication but half this thread is about logical replication being moved to core so we can get scalable distributed clusters in the future - something even fewers users would use but clearly has many benefits by being included in the main release.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: