
Why we lost Uber as a user - areski
https://www.postgresql.org/message-id/5797D5A1.5030009%40agliodbs.com
======
matthewmacleod
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.

~~~
babuskov
> The PoststgreSQL project never fails to impress me.

Except the name is a bit clunky and hard to write ;)

~~~
enave
Maybe, but it's a much better name than mysql. I feel like a little kid every
time I say "my" anything.

~~~
kirubakaran
"My" of MySQL is Monty's daughter.

 _" He lives in Helsinki with his second wife Anna and daughter Maria (after
whom MariaDB was named), and has a daughter My (after whom MySQL was
named)[14] and a son Max (giving the name for MaxDB) from his first marriage"_
[https://en.wikipedia.org/wiki/Michael_Widenius](https://en.wikipedia.org/wiki/Michael_Widenius)

~~~
Grishnakh
Also, I'm pretty sure most of us are mispronouncing MySQL: IIRC, "My" (the
Finnish name of his daughter) is pronounced like English "Me".

~~~
sluukkonen
The y is pronounced like the ü in über.

~~~
CamperBob2
Actually it's more like the 'j' in Eyjafjallajökull.

~~~
zaroth
Wait, I think you are all just fucking with me...

------
gnur
Wow, nice explanation. I was expecting a lengthy post with refuting everything
uber said and explaining why pgsql was a better choice and uber was wrong.

Nice and clean post showing that acknowledging a weakness isn't a terrible
choice.

I do wonder whether a different data structure would have mitigated the issue
instead of transitioning to a different storage engine.

~~~
collyw
Yes, I have a lot more respect for this than say MongoDb which claims to be
great at everything.

~~~
DiabloD3
For the kind of stuff Uber stores, they may actually be doing it wrong (given
what that Postgre mailing list post says) because that is one hell of an ugly
use case for _any_ DB.

I would have tried solving it by loading a dual E5v4 server full of 3TB and a
slew of SSDs for L2ARC+ZIL under ZFS: more SSDs > bigger SSDs because the
absolute worst case SSD performance that _any and all_ SSDs suffer from is
random _reads_ (not writes) can slow to 200MB/sec even on those insanely fast
"enterprise" PCI-E SSDs that do 2-4GB/sec continuous reads.

Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and MS
SQL. Unless you're doing something that is truly not suited for SQL (or SQL is
insanely overkill), or you're Google and have a database in the hundreds or
thousands of TB and literally have to write your own database (they went from
almost inventing mapreduce, to going full circle back to full scale
distributed RDBMS SQL with F1, which I wish they'd open source), any other
database is just going to be a pain in the ass, buggy, and full of gotchas and
undiscovered corner cases simply because it doesn't have over a decade of
development and millions of users behind it.

Also, I have not included MySQL for obvious reasons: fun for toy SQL DBs where
sqlite isn't a good fit, but not for enterprise use by any means. Uber
switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber
investor right now.

~~~
vegabook
_> Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and
MS SQL_

This is total bullshit. Even a modest size database (3-5 terabyte) for a small
company like mine, chokes a relational database bigtime on time series.
Especially the modern use cases where you are ingesting fast. You need
Cassandra or Hbase which are very serious pieces of technology and are
definitely "worth using", and will crush any of the four relational dinosaurs
you mention in that space at comparable cost, and with embarrassingly better
scalability. And by the way, that space is not some corner case, it is
probably the major growth area of the next computing era.

~~~
PeCaN
There are column-oriented relational databases for that. DB2 and SQL Server
both implement columnar systems for OLAP-esque workloads pretty well, and I
think Oracle has something like that as well. In the Free software space,
MonetDB is pretty good and I believe there's some Postgres extension to store
data column-wise (which is probably not competitive with ground-up column
stores like MonetDB, but beats row-wise storage for certain workloads).

You don't need to give up proven relational databases for this web-scale
bullshit. Financial companies have been doing hundreds of times “modern use
cases where you are ingesting fast” for decades. KDB+ is the darling of that
industry, but DB2 is pretty popular (IIRC) as well as some other niche
options.

Right tool for the right job, basically. I have nothing against Cassandra or
HBase, and they're both quite impressive pieces of engineering. But they're
not an alternative to relational databases; rather, a complement for _very_
niche use-cases. I see NoSQL stuff get used for “performance and scalability”
in places where a columnar relational DB would scale just fine and bring the
benefits of a relational database. I'm all for HBase for non-relational use-
cases, but those are rather more rare than people seem to think (and end up
with an ad hoc relational model because of it).

~~~
jacques_chester
For columnar and massively-parallel workloads, Greenplum was opensourced this
year[0]. It was originally forked from PostgreSQL 8.2.

There's also Apache HAWQ (incubating), which takes Greenplum's SQL parser and
distributed query planner to use as front-ends for Hadoop[1].

Disclaimer: I work for Pivotal, which opensourced these systems.

[0] [http://greenplum.org/](http://greenplum.org/)

[1] [http://hawq.incubator.apache.org/](http://hawq.incubator.apache.org/)

~~~
PeCaN
Whoa, that looks quite slick. Thanks for your work!

~~~
jacques_chester
All credit belongs to my peers in the Big Data division, and the engineering
directors who successfully argued to opensource our entire portfolio of data
tech (Greenplum, HAWQ, Gemfire and MADLib).

------
cel1ne
> "In some ways, people worry about the bugs they have seen, not the bugs they
> haven't seen." [0]

This is a key take-away for me. I used mySQL extensively and switched to
postgres for everything years back. I would need extremely good reasons to use
mySQL again. What you get with postgres is a lot more consistency and peace-
of-mind, in my opinion.

[0] [https://www.postgresql.org/message-
id/20160727160408.GA23585...](https://www.postgresql.org/message-
id/20160727160408.GA23585%40momjian.us)

------
methehack
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. One has to ask: for how long
will it work? Surely the clock is running out on such a design.

~~~
angelbob
You're not wrong. But mostly we haven't collectively agreed that relational
databases aren't great for highly-indexed rapid-update join tables.

I think we will at some point. That's the primary original use case for a lot
of NoSQL, and the reason Twitter had so much trouble with relational
databases.

But these are cultural understandings, and those move slowly. Also, we're
poorly (collectively) equipped to handle subtlety in these discussions, so
mostly we're trying to move from "relational databases are perfect for all use
cases" to "NoSQL databases are perfect for all use cases" \-- which is even
_less_ true, not more true.

Culturally, this is a hard thing to keep in our collective brain.

~~~
duaneb
How has NoSQL addressed join tables? All the approaches I've seen are much,
much slower than with a traditionally vertically scaled relational database—or
by moving away from joining altogether—it's traditionally been the twin
pressures of scale and replication that force people to move to a distributed
database.

~~~
bind
NoSQL doesn't do table joins.

~~~
duaneb
Well, F1 does. I'm fairly sure FoundationDB did too. It isn't incompatible--
I'd argue joins are natural for certain tasks, and certainly reduce developer
load, especially if the latency isn't a driving priority.

Yes, that's SQL, but the term nosql was always orthogonal to the priorities of
the movement (horizontal scalability).

------
cemerick
This only talks about a particular write amplification issue. A far better
message IMO is just a few clicks upthread:
[https://www.postgresql.org/message-
id/579795DF.10502%40comma...](https://www.postgresql.org/message-
id/579795DF.10502%40commandprompt.com)

Provides a link to the rationale post from uber ([https://eng.uber.com/mysql-
migration/](https://eng.uber.com/mysql-migration/)), and a tl;dr of it. Prior
discussion here:
[https://news.ycombinator.com/item?id=12166585](https://news.ycombinator.com/item?id=12166585)

~~~
dspillett
It is nice to see that while the thread does question some of Uber's
motivation for the change, where there is a genuine problem with their product
there is a frank admission (with quotes like "this is a common problem case we
don't have an answer for yet" and "limitations of our current replication
system are real, or we wouldn't have so many people working on alternatives")
which people discuss seriously (asking for clarification and/or suggesting
ways forward) rather than reacting with a knee-jerk defensive posture.

------
BilalBudhani
A huge respect for PostgreSQL team on (always) being so transparent about
their shortcomings and giving credits where its due (InnoDB). Posts like these
makes me more confident on PostgreSQL as a product.

Also I'd like to take this moment and address those people, who will start
rubbing this "Uber switched to MySQL from PostgreSQL" argument without
considering that not every app is "Uber". You can't simply take their use case
and start throwing stuff against PostgreSQL.

------
jhh
The attitude with which the article is discussed in the mailing list is
admirable.

~~~
coldtea
Couldn't help contrasting it to some popular programming language mailing
lists, especially a CSP inspired language by a major search company.

~~~
anamoulous
Couldn't help contrasting it to the comments on this very site.

------
brightball
In reading that, my first thought was "why in the world would Uber do that?"

In every single performance tuning a scale story that I've read over the past
decade, the very first point of order is: remove joins from high traffic
queries. It seems like Uber has gone the complete opposite direction.

~~~
emn13
It's unrealistic to remove all joins (usually), and most joins aren't very
expensive. In normal cases a join is strictly faster than running an extra
query to get that extra data.

Joins start getting particularly tricky when you do expensive stuff like
filter over the correlated results of many tables. But in those cases, there's
also no easy alternative: you'll need to redesign the way you store your data,
if possible.

------
solarengineer
Here's the entire thread: [https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401...](https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401b-50a9-a1a02c53d9e6%402ndquadrant.fr#7663dfec-e46a-401b-50a9-a1a02c53d9e6@2ndquadrant.fr)

------
jjp
The original Uber blog post that led to the discussion -
[https://eng.uber.com/mysql-migration/](https://eng.uber.com/mysql-migration/)

------
tombert
I think it's very cool that Postgres didn't just post some long thing about
Uber saying "they're using it wrong omg!!!" and instead address the problems,
understand their decision, and move on. I think that's very cool, there's
clearly a good team working on this DB.

------
merb
Actually after watching their video. I think that even MySQL wouldn't helped
them. Ignoring disk space full is really not a good idea.

------
MadWombat
I see some comments call this a "very specific user case". This is not. Pretty
much every major web project is going to have tables like that. User sessions
are just one example. Sure, you can design around this, but it is a problem
and no design is going to make it completely go away.

~~~
fleetfox
Storing sessions in rdbms is a rather poor choice espesially at scale.

~~~
encoderer
On the other hand, sessions are important and if you're only using redis/etc
for caching and not as a primary data store, it may not be a very good idea to
treat it as a primary store of session data.

Sessions are vital for any product that works better with logged-in users.

------
erikb
I agree it's a nice thing. But some kind of answer may also be good. Like
restructuring your data to become faster.

I also wonder what happened the last few (10) years. When I was in university
I'm pretty sure I learned that JOIN was Satan's mother and if you have a big
DB you need to avoid JOINs as much as possible. That's not a big deal today
anymore, it seems.

~~~
mnw21cam
That kind of thinking is probably what spawned the whole "do the join in the
app, not the database" anti-pattern. The truth is, the database is going to be
_much_ faster at performing a join than loading the contents of two tables
into your app and iterating. If you need the data that results from doing a
join, doing a join is the best way to get it.

Unless you already have your entire database in-memory in your app, that is.
In that case, why do you have a database?

~~~
dagss
What you are missing here is "denormalization" \-- e.g. many-to-many
relationships. You can either use a JOIN with a table on a "normalized"
database, or keep managing the _result_ of the join in application code.
Loading the entire tables into application code very seldom has anything to do
with it...

A more realistic example is, do you get Alice's pets by doing a JOIN on tables
Person, Pet, PetOwnedByPerson ("SQL") -- or by having an array column "pets"
in Person? ("NoSQL")

~~~
erikb
Yes "denormalization" was the word for that. Is that still a thing?

~~~
lostcolony
It's a term used frequently in NoSQL land, to explain a key difference to
people coming from SQL. In SQL land, normalizing your data is still the
canonical thing to do, and I don't recall anyone in academia officially
talking about denormalizing ever having its place...but in industry, the
realities of use cases and performance have meant its usage. But I don't know
that it's a standard tool given out to graduating software devs and DBAs.

~~~
baakss
The link I posted above is a common SQL land usage. Dimensional modeling in a
star schema is very widely used in BI projects.

There's actually two competing philosophies on data warehousing (Inmon and
Kimball), but I've only ever used Kimball's method, which favors
denormalization.

[http://www.computerweekly.com/tip/Inmon-vs-Kimball-Which-
app...](http://www.computerweekly.com/tip/Inmon-vs-Kimball-Which-approach-is-
suitable-for-your-data-warehouse)

------
grandalf
How well will INNODB scale for this particular use case? It seems that the
architecture is a bit too reliant on the complex performance characteristics
of one subsystem.

------
ZanyProgrammer
Its weird seeing a post mortem for losing a user (I really want to say
customer) from a piece of FOSS. Its also weird (still!) to consider Uber a
tech company, rather than a company that happens to use tech.

~~~
menzoic
Just curious, what's your definition of "Tech Company"? All services provided
by Uber are purely technical. Drivers and Riders are customers of Uber's
technology. The full name of the company is "Uber Technologies Inc."

~~~
rplst8
I wasn't sure what to think of that comment either when I first read it, but I
sort of see where he is coming from. One side you have companies like Oracle,
Microsoft, and IBM types that actually develop new forms of technology and
sell the technology to people. Then there are companies that leverage
technology in other industries to "disrupt" like OpenTable, Uber, and AirBnB.
Then there are companies like Google and Facebook that straddle that line.
They've developed and contributed back huge advances in technology, they
mostly make their money from another industry, but also sell some tech in
certain areas (mostly Google).

~~~
menzoic
Interesting perspective, but I don't think selling technology directly should
be the requirement. I think a company is a "Tech Company" when the core
product is technology produced by the company. I consider Facebook and Twitter
to be tech companies, even though they don't sell technology directly. AirBnB
and Uber have some decent open source contributions and have the ability to
contribute back huge advances but probably won't focus as much on that until
they're profitable.

------
cyberferret
I am guessing that VACUUM only kicks in for row deletions? With that busy a
table, can't you just bypass VACUUM and reuse dead keys? I am assuming because
you are talking indexes here, you are talking fixed length records and not
dynamically allocated VARCHARs etc.??

~~~
cesarb
Postgres uses MVCC, which is basically copy-on-write: every UPDATE to a row
actually creates a new row. Once all transactions that could see the old row
have finished, the old row can be pruned.

~~~
cyberferret
Ah, thanks for the clarification - the bloat issue makes more sense now.

------
Myrmornis
It would be more helpful if this linked to the entire thread:

[https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401...](https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401b-50a9-a1a02c53d9e6%402ndquadrant.fr)

------
jimktrains2
Here is the original message in the thread, and it gives some additional
reasons as well.

[https://www.postgresql.org/message-
id/579795DF.10502%40comma...](https://www.postgresql.org/message-
id/579795DF.10502%40commandprompt.com)

------
curiousgal
Are there any recommended resources to extensively learn about databases?

------
cobbzilla
great explanation by the Postgres crew.

it makes me wonder, though: if I had a table with 50k rows, updated hundreds
of times per second and used in joins throughout the database, is there any
way I can just stick that whole table into memcached or redis? I know there
are some cases where this works, some where it doesn't. curious if this option
was explored.

~~~
bsaul
Completely agreee. Highly mutable => in memory ( then add a secondary stream
for colder storage backups just in case).

A relational db is originaly meant for fetching data from a slow storage to a
fast one, and the other way around, in a smart way. Doing it 500 times a
second isn't a scenario for any db.

Build your own in memory data + process tructure, maybe using something like
and agent network and using eg akka or erlang for failovers.

I'm curious as to why uber had to rely on a relational db for this case...

~~~
tylermauthe
It's often simpler to keep data in a relational DB for reporting, especially
if you've got data lake tooling -- it's just easier to get wider insights if
your data is stored relationally. I know it's possible to do this without
relational DB, but you get it for free with SQL.

As you say though, put it in memory first and write it out to a DB every now
and then.

------
systematical
If only politicians gave answers like that, country would be a better place.
Kudos for the answer. I use both MySQL and Postgresql depending on my use
case.

------
machine-wisdom
The whole discussion (this and [1] and [2]) is very interesting. I find it
that Uber is holding on the ACID guarantees of a relational DB so much, in a
way that is clearly hurting them. IMHO it will do them a big service to break
down the responsibility of such a DB into multiple distributed systems that
can work on a global scale. For example, a distributed lock system can help
them when they need transactions. If they keep moving from one relational DB
to another, they are bound to hit problems of Availability because they are
choosing very strong Consistency, and the CAP theorem says we can't have it
all (Partition tolerance is required).

[1]
[https://news.ycombinator.com/item?id=12166585](https://news.ycombinator.com/item?id=12166585)
[2]
[https://news.ycombinator.com/item?id=12179222](https://news.ycombinator.com/item?id=12179222)

------
bind
Tom Lane's response:

 _this seems like an annoyance, not a time-for-a-new-database kind of
problem._

[https://www.postgresql.org/messageid/13659.1469570853%40sss....](https://www.postgresql.org/messageid/13659.1469570853%40sss.pgh.pa.us)

------
geophile
Question about Postgres architecture: Why were secondary indexes designed to
refer to ctids instead of primary keys?

~~~
Jweb_Guru
Among other things, there's a substantial performance penalty for secondary
index lookups with clustered indices (since they need to traverse two index
structures).

~~~
GrayShade
I'm not sure about the other databases, but in MS SQL you can include columns
in the index leaves. This mitigates the need for the second lookup and can be
even faster than the Postgres approach.

~~~
Jweb_Guru
Keep in mind that the complaint Uber had was with writes in Postgres affecting
secondary indices that _didn 't_ cover a particular column. As far as I know,
in _all_ databases, if a covered column is modified the secondary index must
be, too. So that does not really resolve Uber's problem.

Additionally, I can't quite recall whether this is the case in MS SQL (since
it uses pessimistic locking by default, not snapshot isolation, which has
different performance characteristics), but in most MVCC architectures there's
the additional problem that the underlying row value could have been changed
concurrently with your query (e.g., deleted or modified). While this might not
seem so bad for simple row-level lookups, this gets much more problematic if
you are doing something like a range query, where the index might contain rows
that weren't in the database at the beginning of your snapshot. There are a
variety of ways of dealing with that problem, but most of them involve
increased write traffic (index sizes get even more bloated because now they
need versioning information), increased read traffic (index reads that touch
out-of-date rows may have to follow an undo pointer, requiring the extra seeks
you were trying to avoid in the first place), more locking (for instance, you
could lock the entire index when a transaction modified it to keep it
consistent--but that would decrease concurrency--or you could try to do range
locking--which can lead to increased probability of deadlocks and also
decreases concurrency and increases contention on the lock manager),
opportunistic optimizations that only work on mostly-immutable data (Postgres
and HyPer's solutions is to maintain a much smaller visibility map with bits
indicating whether it's safe to assume the index is unchanged), or giving up
multi-key read consistency (I'm assuming if this were an option you would be
using another storage engine, because lots of them can perform unbelievably
well if that restriction is relaxed!).

My point being, there's no such thing as a free lunch. Personally, I'm usually
extremely happy to give up on pessimistic locking for the concurrency benefits
of MVCC, and index utility decreases sharply as it gets larger, but as with
many other things it entirely depends on your workload. Two-phase locking
actually works far better than MVCC of any sort under heavy contention with
short transactions (what Uber is apparently doing), so they really probably
should have investigated SQL Server or another database optimized for
pessimistic concurrency control.

------
mrfusion
I don't understand if they mean that foreign key relationships are
contributing to the problem. If so is it possible to turn off foreign key
constaints during a big load?

Would it be worth removing indexes during a big load?

(Currently fighting with an etl that can't get above 500 rows / second even
after using copy from)

~~~
richardwhiuk
The reason the indexes are their is because the table is involved in multiple
JOINs, which without the indexes are very slow. I suspect it's a straight
index, not a foreign key constraint.

------
eric_the_read
This might explain a lot of the performance problems we've seen trying to use
Postgresql as an event store, dumping some 10s of millions of rows/day into a
table that has a few indexes (no foreign keys, but trying to speed up
queries). Sounds like it's time to investigate alternatives.

~~~
wmfiv
I would think it's unrelated. The issue described by Uber and the Postgres
team is specifically related to UPDATEs against highly indexed tables. In an
event store the data is typically completely immutable.

------
combatentropy
This later comment in the thread ([https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401...](https://www.postgresql.org/message-
id/flat/7663dfec-e46a-401b-50a9-a1a02c53d9e6%402ndquadrant.fr)), by Merlin
Moncure, describes a set-up that most applications have, and I agree with his
assessment of it:

    
    
        Taking a step back, from the outside, it looks like uber:
        *) has a very thick middleware, very thin database with respect to
        logic and complexity
        *) has a very high priority on quick and cheap (in terms of bandwidth)
        replication
        *) has decided the database needs to be interchangeable
        *) is not afraid to make weak or erroneous technical justifications as
        a basis of stack selection (the futex vs ipc argument I felt was
        particularly awful -- it ignored the fact we use spinlocks)
    
        The very fact that they swapped it out so easily suggests that they
        were not utilizing the database as they could have, and a different
        technical team might have come to a different result.   Postgres is a
        very general system and rewards deep knowledge such that it can
        outperform even specialty systems in the hands of a capable developer . . .
    

It's all the rage to use an object-relational wrapper to abstract away the
database brand, so that the database can be "interchangeable." In my 11 years
experience with web apps and databases, particularly Postgres, this is a false
economy:

\- When you use an object-relational wrapper, you are trading one kind of
lock-in for another. Instead of locking yourself into Postgres, you are
locking yourself into PHP. That seems a good trade to most developers, who
know their middleware language better than SQL.

\- However I have found that moving your application code from the middle
layer, to SQL, results in shorter code and much faster execution. I don't mean
moving the Python code into Postgres functions written in PL/Python (which you
can do). I mean porting them to SQL. The simplest example is if your first
version of your application just used SQL to fetch all the rows from the
database and using a Python if-statement to find the rows you need: rewriting
the Python if-statement as an SQL where-clause will be much faster. I'm sure
few of you are doing something like that, but there are many, more complex
examples like that, which I have learned and slowly replaced over the years.

\- Furthermore SQL is just like any other language in that there are many ways
to do the same thing, and some ways are a thousand times faster than others.
People who only know basic SQL likely are writing inefficient apps. I have
often rewritten queries to use a fraction of the memory and time they were
using.

Moral of the story: Learn more SQL, instead of learning some avant-garde
storage engine. Stepping deeper into PostgreSQL (and thereby locking yourself
more and more into it) is often better than locking yourself deeper into
Python, PHP, or whatever your middle language is. Who knows, you may want to
switch out your middle language before you want to switch out Postgres!

I try to make Postgres my "application": put all your business logic in there.
It may have an arcane "user-input interface" (SELECT . . . FROM sometable
WHERE . . .) and a primitive "user-output interface" (plain tables) but that's
where the middleware finally comes in, to cover the queries with checkboxes
and buttons, and to decorate the output into various boxes, color, layout, and
type, and maybe some nice images, graphs, and so on.

~~~
MichaelGG
Uber's original post made the case that their engineers might not understand
that keeping a DB transaction open while sending an email is not a good idea.
Either I have an incredibly unrealistic expectation for "engineers" or Uber's
team has low standards.

------
dumbfounder
Sounds like postgres needs to support pluggable storage engines. I am sure
Uber (and many others) would have paid some license fee to someone who
developed a storage engine that fixed this use case. Think of how much it cost
them to switch...

~~~
spotman
Yea would be amazing to see an innodb backend for PG!

( I'll let myself out ;)

~~~
spacehunt
There _is_ a Foreign Data Wrapper that wraps MySQL[1]. Not exactly the same
thing though, and no idea how well it works.

[1]
[https://github.com/EnterpriseDB/mysql_fdw](https://github.com/EnterpriseDB/mysql_fdw)

~~~
dumbfounder
I can tell you it doesn't work very well for wrapping remote postgres
tables... it doesn't even send the where clause to the remote server, instead
does a table scan across the network and matches locally.

~~~
zejn
Depends which Postgres version you are using: 9.1 added read only FDW support,
9.3 made it writable, 9.5 also has join pushdown into remote table.

Obviously, a lot depends on the FDW extension you are using - it doesn't help
if there is support in postgres, if your specific extension does not utilize
it.

------
neves
I've already read 2 very long about this issue, but this very succinct text is
really way better than any of others. The best computer programming article
I've read in months.

------
EugeneOZ
Initial email is even more impressive - huge respect for this style.

------
jrochkind1
Refreshing alternative to many posts saying "It wasn't really about postgres
at all"

------
scotty79
That's the mature way to react to reality. Vacuuming can be a problem for
users.

------
zhangela
What does VACUUM, SNAPSHOT TOO OLD, HOT mean?

------
landmark3
one other reason is that postgresql.org forum comes straight from 1984

~~~
mixedCase
Yeah we should switch everything to Mongo DB. They have a pretty website after
all.

~~~
boubiyeah
Almost as importantly, it is web scale and thus also uber scale.

