Live data from Hacker News

Why we lost Uber as a user

postgresql.org

181–190 of 310 posts

Re: Why we lost Uber as a user

#182
post #20

Earlier quoted context omitted.

Also, wasn't there a ridiculous issue that they had where the db can't be bigger than 4gb on a 32 bit file system because that's the largest size a file can have...?

Yes, apparently the limit on 32-bit is 2GB actually. MongoDB has always stated upfront that 32-bit architectures are not recommended for production use for precisely this reason: http://blog.mongodb.org/post/137788967/32-bit-limitations This has also has been stated on their download page for 32-bit binaries as well.

Oracle 9 on 32 bit can handle 32GiB databases without any issue, and bigger setup to use more that a single file per table space. And Oracle 9 it's old.

Note: I hate Oracle DB, but I must work with Oracle 9/10/11/2 DBs because is what our clients have.

Re: Why we lost Uber as a user

#183
post #20

Earlier quoted context omitted.

Also, wasn't there a ridiculous issue that they had where the db can't be bigger than 4gb on a 32 bit file system because that's the largest size a file can have...?

While I don't care about mongoDB, who's running 32bit anymore? And for a production DB?

Spain public administrations.

Re: Why we lost Uber as a user

#184

Earlier quoted context omitted.

>Mysql eats and corrupts data by design. I'd like to have a source on that, would help shutdown a lot of MySQL discussions if true.

The docs describe a lot of ways data can be corrupted if you don't have the right configuration and database engine: https://dev.mysql.com/doc/refman/5.7/en/constraint-invalid-d...

I don't think any of those apply in strict mode, which is the default in recent versions of MySQL.

https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

"The default SQL mode in MySQL 5.7 includes these modes: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, and NO_ENGINE_SUBSTITUTION."

Re: Why we lost Uber as a user

#186

Earlier quoted context omitted.

> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)

A small bit of history from Tom Lane one of the biggest contributors to the project "Arguably, the 1996 decision to call it PostgreSQL instead of reverting to plain Postgres was the single worst mistake this project ever made." - https://www.postgresql.org/message-id/2693.1152762174@sss.pg...

> It seems too late to change it now

That's what they said in 1996. Then they said it again in 2006. In 2026 when its interwoven in all sorts of AI systems and still causing confusion, they will be looking back thinking why didn't they fix it back in 2017 when they still could. "Now" is always the right time, it's never too late.

Re: Why we lost Uber as a user

#187

Does anyone else think the scenario in the explanation is an unreasonable request to make of a relational database? I think that if you've created a design that requires you to update a 50K row table 500 times a second that itself is heavily indexed and used heavily in joins, you have a software design problem more than a database problem. I wouldn't expect any database to handle that and am surprised that mysql does…

[deleted]

Re: Why we lost Uber as a user

#188

The PoststgreSQL project never fails to impress me. I know that there are some use cases which are not currently covered by it versus alternatives, but I have consistently got the feeling that everybody involved in the project is supremely professional and interested in building an excellent database – and the focus is on how to work to fix these use cases, instead of pointless mudslinging. Class act.

True, they're admitting there's a problem (which exists for this very specific user case) and not just deflecting the criticism. I'm impressed, I'd say a lot of projects couldn't have handled this so nicely

They're trying to "Do One Thing And Do It Well". It's always interesting how core UNIX philosophy often gets lost in Startup Culture's rush to "Disrupt The World".

Re: Why we lost Uber as a user

#189

Earlier quoted context omitted.

Uber relies entirely on their database. If the database is slow, or cannot be considered reliable under extreme load, or can lose data in ways that are hard to recover, then Uber can potentially lose a lot of money especially during peak hours. Yes, I'm aware there are systems for MySQL to handle failure, but I'm also aware of the systems for Postgre, and Postgre's failure handling seem to be far saner and easier to…

Here is an Uber engineer's talk about their worst outage ever. 16 hours of downtime for their API as they repeatedly try and fail to promote a new postgresql master and reparent slaves to it. https://www.youtube.com/watch?v=bNeZYVIfskc&t=26m54s https://surge.omniti.com/2015/images/presentations/MattRanne... (Slides 39-63)

the problem mostly happened cause ppl just ignored the "running out of disk space" message. Would happen on mysql, too. And I really wouldn't want that to happen on galera, I guess that would be a way bigger desaster.

Re: Why we lost Uber as a user

#190
post #71
post #31

Earlier quoted context omitted.

why isn't the tech that a bank would create in house be categorized similarly to the tech uber creates?

Without banking technology, a bank can still be a bank and provide its distinctively unique services, just slower. It worked for the Templars, and they didn't even have double-entry bookkeeping. Without Uber technology, Uber would not exist - it would just be Uber Taxi Inc., a perfectly ordinary taxi company indistinguishable from all others.

Well, not really. Their product is really a two-sided market with prices controlled by themselves - matching drivers, unregulated and not employed by Uber, to passengers. They could do that with nothing more than a call center and a spreadsheet of roughly where drivers are if the tech didn't exist, and it'd still be cheaper and avoid the monopoly of the taxi companies.

Whether it'd largely avoid the ire of law enforcement if they couldn't hide behind their tech is a different matter.

Post reply on HN