5 ms·

Looking back, I never understood why it didn't win the database wars in the 90's against MySQL (in the famous LAMP stack)? Was it that it was harder to administ

Looking back, I never understood why it didn't win the database wars in the 90's against MySQL (in the famous LAMP stack)? Was it that it was harder to administrate?

noir_lord 9y ago
MySQL had faster reads and better clustering out the box. It did a lot of questionable things to get that (mostly MyISAM, innodb is better) and it was a lot more tolerant of shoddy data modelling (again questionable).
ForHackernews 9y ago
Manual vacuum used to be a pain on Postgres.
mmsimanga 9y ago
I was a part-time web developer at the time. I remember that PostgreSQL didn't run on Windows. Most hosting providers also only supported MySQL. Back then I used [Xampp](https://www.apachefriends.org/index.html https://www.apachefriends.org/index.html) to do all my development on Windows.
wvenable 9y ago
As a developer from that time, Postgres was more fiddly and unnecessarily complex. It was probably always an objectively better DBMS (except at replication) but MySQL was simpler and more predictable. And subsequently the entire ecosystem fit together better with MySQL (the LAMP stack as you mentioned).
takeda 9y ago
From my perspective it was due to PHP being really popular back then, and MySQL was a first class citizen there. Then Python showed up, which reversed it (Postgres is defacto standard database for it). Acquisition of MySQL by Oracle sped up this change further.
smacktoward 9y ago
Postgres focused on being accurate. MySQL focused on being fast. It turned out people cared a lot more about being fast than about being accurate.
- tabtab 9y ago
  Different target audience. MySQL originally targeted dot-com start-ups while PostgreSQL focused on being a reliable longer-term platform for established companies or niches. It's not going to hurt a web start up if they lose 1 out of every 5,000 customer transactions (posts), but that ratio would squash a financial application.
raarts 9y ago
I ran a hosting company in the nineties. My experience: in those days everybody needed speed. Hardware was underpowered and number of hits unexpected. Connection pooling was either unknown, or very new, in any case, not enabled by default. So a hit required a new connection to be started. This was way easier with MySQL, which was just a socket connection, where PostgreSQL started an entire new process for each connection. Way to slow. Because of this people even took for granted that you needed to check MySQL databases for errors every night.
runako 9y ago
IIRC setting up and doing basic admin (creating users, etc.) was harder for PG than MySQL.
sbuttgereit 9y ago
Having been involved in enterprise related technology at the time, I can tell you that there were a number of factors, some of which I think may have been alluded to here. * MySQL was looked at as cost effective and fast data store for developing less than mission critical things like backing web front ends; and back then much of the web work was really less than mission critical for a lot of organizations; this meant that so long as it was fast and didn't burden these new "web developer" types with too much ceremony, it was a compelling choice. Postgres of that era even then boasted a much better and more "correct" set of features that would appeal to enterprises, but wasn't all that fast and did bring that extra effort that most of these reckless developers on the fringe didn't want. * For enterprise work, Oracle, DB2, or to a lesser extent MSSQL where the choices. Open source was distrusted (what do you mean "free", what's the catch? Must not be worth anything if you can't charge for it. Nobody got fired for buying IBM, MS, etc). So the people that would most likely look at the trade offs in Postgres of that time favorably were the ones least likely to entertain it. The innovation was on the web side of the world, and there I go back to my first point. * PHP was also a big deal back then. Our company was convinced by one of our sysadmins to let him greenfield a help desk application for our internal support (~1997/98). PHP was the obvious choice because it was so easy and fast to write code that worked and was web focused... and the default database choice was MySQL. (We went way out on a limb and installed it on this new OS called Linux, Slackware if I recall correctly). PHP and its good support of MySQL as data store made it the default choice. Postgres wasn't even on the radar or a discussion point. * MySQL was developed by a consulting company with an interest in promoting it. Postgres didn't have that kind of directly interested marketing support. Sure you could get the code and install it, but there really was no marketing as compared to MySQL. So, easy to use, relatively friction-less technologies; targeted at really and an new technology industry that was just starting to take off; and that the concerns of that new industry didn't match up well with the strengths and weaknesses of the Postgres you could get back then, but did match up well with MySQL.... yep, I think all of those are reasons why things turned out as they did. BTW... I say this as someone that was never terribly fond of MySQL and still not. Back then I was an Oracle guy, since about Postgres v8.0, I've been favoring Postgres.
combatentropy 9y ago
Based on the other replies about MySQL being simpler and faster, it makes me wonder again why SQLite didn't win.
- zimpenfish 9y ago
  It doesn't allow multiple concurrent writers easily - you have to handle the "SQLITE_BUSY" errors yourself and cope with any changes that might have happened in the interim (although transactions can obviously help.) https://www.sqlite.org/lockingv3.html https://www.sqlite.org/lockingv3.html
- SQLite 9y ago
  SQLite was late to the party. The first code for SQLite was laid down in 2000, years after MySQL was already well-established in the LAMP stack. Also, SQLite is embedded, not client/server. That means that the application needs to run on the same machine that holds the data. And because there is no server to coordinate access, concurrency is necessarily limited. On the other hand, SQLite arrived just in time to get picked by smart phones, and is consequently the most-deployed database software in the world. There are far more instances of SQLite running today than there are MySQL instances.

Looking back, I never understood why it didn't win the database wars in the 90's against MySQL (in the famous LAMP stack)? Was it that it was harder to administrate?

noir_lord 9y ago

MySQL had faster reads and better clustering out the box. It did a lot of questionable things to get that (mostly MyISAM, innodb is better) and it was a lot more tolerant of shoddy data modelling (again questionable).

ForHackernews 9y ago

Manual vacuum used to be a pain on Postgres.

mmsimanga 9y ago

I was a part-time web developer at the time. I remember that PostgreSQL didn't run on Windows. Most hosting providers also only supported MySQL. Back then I used [Xampp](https://www.apachefriends.org/index.html https://www.apachefriends.org/index.html) to do all my development on Windows.

wvenable 9y ago

As a developer from that time, Postgres was more fiddly and unnecessarily complex. It was probably always an objectively better DBMS (except at replication) but MySQL was simpler and more predictable. And subsequently the entire ecosystem fit together better with MySQL (the LAMP stack as you mentioned).

takeda 9y ago

From my perspective it was due to PHP being really popular back then, and MySQL was a first class citizen there. Then Python showed up, which reversed it (Postgres is defacto standard database for it). Acquisition of MySQL by Oracle sped up this change further.

smacktoward 9y ago

Postgres focused on being accurate. MySQL focused on being fast. It turned out people cared a lot more about being fast than about being accurate.

tabtab 9y ago
Different target audience. MySQL originally targeted dot-com start-ups while PostgreSQL focused on being a reliable longer-term platform for established companies or niches. It's not going to hurt a web start up if they lose 1 out of every 5,000 customer transactions (posts), but that ratio would squash a financial application.

raarts 9y ago

I ran a hosting company in the nineties. My experience: in those days everybody needed speed. Hardware was underpowered and number of hits unexpected. Connection pooling was either unknown, or very new, in any case, not enabled by default. So a hit required a new connection to be started. This was way easier with MySQL, which was just a socket connection, where PostgreSQL started an entire new process for each connection. Way to slow. Because of this people even took for granted that you needed to check MySQL databases for errors every night.

runako 9y ago

IIRC setting up and doing basic admin (creating users, etc.) was harder for PG than MySQL.

sbuttgereit 9y ago

Having been involved in enterprise related technology at the time, I can tell you that there were a number of factors, some of which I think may have been alluded to here. * MySQL was looked at as cost effective and fast data store for developing less than mission critical things like backing web front ends; and back then much of the web work was really less than mission critical for a lot of organizations; this meant that so long as it was fast and didn't burden these new "web developer" types with too much ceremony, it was a compelling choice. Postgres of that era even then boasted a much better and more "correct" set of features that would appeal to enterprises, but wasn't all that fast and did bring that extra effort that most of these reckless developers on the fringe didn't want. * For enterprise work, Oracle, DB2, or to a lesser extent MSSQL where the choices. Open source was distrusted (what do you mean "free", what's the catch? Must not be worth anything if you can't charge for it. Nobody got fired for buying IBM, MS, etc). So the people that would most likely look at the trade offs in Postgres of that time favorably were the ones least likely to entertain it. The innovation was on the web side of the world, and there I go back to my first point. * PHP was also a big deal back then. Our company was convinced by one of our sysadmins to let him greenfield a help desk application for our internal support (~1997/98). PHP was the obvious choice because it was so easy and fast to write code that worked and was web focused... and the default database choice was MySQL. (We went way out on a limb and installed it on this new OS called Linux, Slackware if I recall correctly). PHP and its good support of MySQL as data store made it the default choice. Postgres wasn't even on the radar or a discussion point. * MySQL was developed by a consulting company with an interest in promoting it. Postgres didn't have that kind of directly interested marketing support. Sure you could get the code and install it, but there really was no marketing as compared to MySQL. So, easy to use, relatively friction-less technologies; targeted at really and an new technology industry that was just starting to take off; and that the concerns of that new industry didn't match up well with the strengths and weaknesses of the Postgres you could get back then, but did match up well with MySQL.... yep, I think all of those are reasons why things turned out as they did. BTW... I say this as someone that was never terribly fond of MySQL and still not. Back then I was an Oracle guy, since about Postgres v8.0, I've been favoring Postgres.

combatentropy 9y ago

Based on the other replies about MySQL being simpler and faster, it makes me wonder again why SQLite didn't win.

zimpenfish 9y ago
It doesn't allow multiple concurrent writers easily - you have to handle the "SQLITE_BUSY" errors yourself and cope with any changes that might have happened in the interim (although transactions can obviously help.) https://www.sqlite.org/lockingv3.html https://www.sqlite.org/lockingv3.html
SQLite 9y ago
SQLite was late to the party. The first code for SQLite was laid down in 2000, years after MySQL was already well-established in the LAMP stack. Also, SQLite is embedded, not client/server. That means that the application needs to run on the same machine that holds the data. And because there is no server to coordinate access, concurrency is necessarily limited. On the other hand, SQLite arrived just in time to get picked by smart phones, and is consequently the most-deployed database software in the world. There are far more instances of SQLite running today than there are MySQL instances.