3 ms·

> As early as 2001-2002 he had saved entire businesses by migrating them from mysql to postgres. I'm extremely curious how this worked out.

INTPenis 7y ago
Well I was 18-19 so to me these were myths I heard re-told. But all I know is that they had been throwing hardware on a MySQL install to make it work better. He migrated them to postgres and they got much better performance and could get away with less hardware than they had with mysql. That was as much detail that I remember. Keep in mind I said by sheer luck I became a fanboy. Not by experience and competence. That came later.
- mm89 7y ago
  Interesting username, that's for sure!
- patrec 7y ago
  This isn't hard to believe. MySQL basically started out as a key-value store pretending to be a relational database. If you wanted to do KV stuff and didn't care too much about data corruption (or knew the five zillion magic incantations to mostly avoid them) it was fast. But If you wanted joins or expected the query optimizer to do anything for you, you were SOL.
  - ncmncm 7y ago
    The dirty secret of database engine development is that all the things that are hardest to do in the database proper are super-easy to do in the application, given a few judicious architectural choices; but despite that, nobody can count on app writers to do them right. So, DB engine developers have to bust their humps to cover for users' incompetence. A database for competent users can be amazingly simple and fast. But the Market Has Spoken, loud and clear: databases must absorb an indefinitely large amount of complexity to make the job of app writers a tiny bit easier.
    - patrec 7y ago
      I'd be curious to see some examples of what you mean! I think there are definitely cases where DB needs to compensate for bad architecture, but then even competent developers can profit from the flexibility of being able to ad new features ad hoc to an existing db schema/architecture and the DB just magically bailing them out.

INTPenis 7y ago

Well I was 18-19 so to me these were myths I heard re-told. But all I know is that they had been throwing hardware on a MySQL install to make it work better. He migrated them to postgres and they got much better performance and could get away with less hardware than they had with mysql. That was as much detail that I remember. Keep in mind I said by sheer luck I became a fanboy. Not by experience and competence. That came later.

mm89 7y ago
Interesting username, that's for sure!
patrec 7y ago
This isn't hard to believe. MySQL basically started out as a key-value store pretending to be a relational database. If you wanted to do KV stuff and didn't care too much about data corruption (or knew the five zillion magic incantations to mostly avoid them) it was fast. But If you wanted joins or expected the query optimizer to do anything for you, you were SOL.
- ncmncm 7y ago
  The dirty secret of database engine development is that all the things that are hardest to do in the database proper are super-easy to do in the application, given a few judicious architectural choices; but despite that, nobody can count on app writers to do them right. So, DB engine developers have to bust their humps to cover for users' incompetence. A database for competent users can be amazingly simple and fast. But the Market Has Spoken, loud and clear: databases must absorb an indefinitely large amount of complexity to make the job of app writers a tiny bit easier.
  - patrec 7y ago
    I'd be curious to see some examples of what you mean! I think there are definitely cases where DB needs to compensate for bad architecture, but then even competent developers can profit from the flexibility of being able to ad new features ad hoc to an existing db schema/architecture and the DB just magically bailing them out.