Thoughts on Uber’s List of Postgres Limitations
blog.2ndquadrant.com
Thoughts on Uber’s List of Postgres Limitations
1–10 of 108 posts
Re: Thoughts on Uber’s List of Postgres Limitations
#2"Error establishing a database connection"
^ Running on pg too?
Re: Thoughts on Uber’s List of Postgres Limitations
#3"Error establishing a database connection"
Genius !
Re: Thoughts on Uber’s List of Postgres Limitations
#4Re: Thoughts on Uber’s List of Postgres Limitations
#5Might be worth someone writing "a panicky guide to installing varnish" for such database issues. Pretty embarrassing though!
Re: Thoughts on Uber’s List of Postgres Limitations
#6'Error establishing database connection'
How very meta.
Re: Thoughts on Uber’s List of Postgres Limitations
#7I think its worth mentioning again that what Uber ended up using has no resemblence to an RDBMS (single table, manual indexes).
So regardless of whether their complaints are justified or not, it should not be taken as an endorsment of mySQL over postgres, but rather of an endorsement of NoSQL over RDBMS .
Which is really just what every company at these scales do (except for google and f5 if whitepapers are to be considered).
Re: Thoughts on Uber’s List of Postgres Limitations
#8Does anyone know the back story to Uber - why didn't it try to improve Postgres rather than move on to feed on another host?
Re: Thoughts on Uber’s List of Postgres Limitations
#9'Error establishing database connection' How very meta.
HNHOD: Hackernews Hug of Death.
Re: Thoughts on Uber’s List of Postgres Limitations
#10I came here to write a snarky comment, but now I can write two ;)
first: if you think any particular db platform is clearly a winner in "db wars", you are naive. there are so many factors involved in configuring the db, the backend, the frontend etc. that you can always find a case where: the supposedly winning db is failing, or the supposedly worse db is performing perfectly fine. and from my experience, you should always use the platform/framework/language that is best for the current project, not the one you madly love. clearly postgres wasn't working for uber. that does not mean it will not work for your project. i have a recent experience where a binary file of a programming object works much much faster than mysql and solves several other problems. would i say "use binary files instead of rdbms"? of course not. but in this one case it does wonders. the "tech-vs-tech" wars need to end, they are pointless.
second: if you cannot setup your blog to withstand an HN spike then maybe you don't have as much real world experience with scalability (albeit simple) as you might think (hint: static page cache behind cdn will make you almost bulletproof - also, with for example Azure, that's dead cheap).