Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL for Developers

planetscale.com

Post reply on HN
Print view View original

101–110 of 119 posts

Re: MySQL for Developers

#101

Post by melvinmelih »

KronisLV wrote: post #82
hu3 wrote: post #77

Earlier quoted context omitted.

> While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough I see this sentiment often here on HN. Something long the lines of "MySQL is enough for small apps but you want PotgreSQL for serious work." When in practice I find the opposite to be true. PotgreSQL is hard to scale and hard to upgrade when compared…

> What's PostgreSQL comparable list? I'm sure that others can comment on that, but in my experience PL/pgSQL is the killer feature that's hard to beat in PostgreSQL, for those cases where you want to store some amount of logic in the database itself (MySQL stored procedures feel a bit more limited). That said, it's not even the only procedural language that is available: https://www.postgresql.org/docs/current/xplang…

> where you want to store some amount of logic in the database itself

If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Imagine having multiple teams updating that logic without any version control or visibility in what’s stored in pg.

Re: MySQL for Developers

#102

Post by pritambarhate »

ndstephens wrote: post #37
aarondf wrote: post #2

Hey HN, I made this course :D The course is a bit more than 7 hours long split over 64 videos. I was always frustrated by the lack of intermediate database content, it seemed like it was mostly intro stuff, or straight to DBA level. So I read as many database books as I could, read through the official docs, and made this course specifically for application developers. If yall have any feedback I'd love to hear it. I…

This looks great!! Hopefully you can answer a couple questions for me. You mention you're using TablePlus. Doesn't look like it has a free option. Can you recommend another similar database GUI tool so I can "code along"? And is there a database I can connect to and work with? Maybe you answer these at some point in the course, but I didn't see anything in the intro. Also you mention this is for devs and not DBA's. D…

Never used or heard about TablePlus, so don't know how it compares but I have been using https://dbeaver.io/ community edition for years now and it's my go to tool for interacting with relational databases. Highly recommended.

Re: MySQL for Developers

#103

Post by pritambarhate »

hu3 wrote: post #77
KronisLV wrote: post #76

It's really nice to see more content for MySQL/MariaDB still being made, since it feels like they are still good solutions for a whole variety of situations! While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough!

> While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough I see this sentiment often here on HN. Something long the lines of "MySQL is enough for small apps but you want PotgreSQL for serious work." When in practice I find the opposite to be true. PotgreSQL is hard to scale and hard to upgrade when compared…

This kind of argument that XYZ company uses ABC software so it's also good for my project is not correct. Your requirements and their requirements are different. Also for many of the above companies, when they were started MySQL used to be the popular solution, so they started with it and stayed with it. The way Facebook or Uber uses MySQL is not how you will use it.

Both PostgreSQL and MySQL are powerful databases and if you have right people with proper knowledge highly scalable systems can be developed with both.

The reason PostgreSQL is recommended in last 8-10 years is because just before that time, though MySQL was very popular it had some issues which were solved by PostgreSQL. So when web developers encountered those problems and they saw that PostgreSQL didn't have those issues, they started recommending PostgreSQL.

In my personal case, I was responsible for managing a Wordpress site with a few million visitors every day. (This is before AWS RDS, we had to set replication manually in those days) We had set up replication with MySQL 5.6. At that time MySQL replication had a few issues, and it used to break every few days.

At that time PostgreSQL replication which I was using in other projects was rock solid. So I started recommending PostgreSQL over MySQL. For others they have similar stories but for different issues they faced in MySQL.

Over the years of MySQL has improved and so has PostgreSQL.

Re: MySQL for Developers

#104

Post by jasonkester »

melvinmelih wrote: post #101
KronisLV wrote: post #82

Earlier quoted context omitted.

> What's PostgreSQL comparable list? I'm sure that others can comment on that, but in my experience PL/pgSQL is the killer feature that's hard to beat in PostgreSQL, for those cases where you want to store some amount of logic in the database itself (MySQL stored procedures feel a bit more limited). That said, it's not even the only procedural language that is available: https://www.postgresql.org/docs/current/xplang…

> where you want to store some amount of logic in the database itself If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Imagine having multiple teams updating that logic without any version control or visibility in what’s stored in pg.

Version control works just as well for .sql files as it does for any other code extension.

If your shop isn't using version control for the database, that's the problem.

Re: MySQL for Developers

#105

Post by elygre »

melvinmelih wrote: post #101
KronisLV wrote: post #82

Earlier quoted context omitted.

> What's PostgreSQL comparable list? I'm sure that others can comment on that, but in my experience PL/pgSQL is the killer feature that's hard to beat in PostgreSQL, for those cases where you want to store some amount of logic in the database itself (MySQL stored procedures feel a bit more limited). That said, it's not even the only procedural language that is available: https://www.postgresql.org/docs/current/xplang…

> where you want to store some amount of logic in the database itself If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Imagine having multiple teams updating that logic without any version control or visibility in what’s stored in pg.

Git. Git works great.

Re: MySQL for Developers

#106

Post by pritambarhate »

samlambert wrote: post #85
mulmen wrote: post #80

Earlier quoted context omitted.

> What's PostgreSQL comparable list? Netflix, Instagram, Spotify, Skype, Reddit, Twitch, Yahoo. e: removed Uber.

Yahoo, Uber, Instagram, and Spotify all run on MySQL. https://www.uber.com/en-JP/blog/postgres-to-mysql-migration/

Instagram definitely runs on PostgreSQL. Here is official Instagram engineering blog mentioning the same: https://instagram-engineering.com/what-powers-instagram-hund...

> Most of our data (users, photo metadata, tags, etc) lives in PostgreSQL; we’ve previously written about how we shard across our different Postgres instances

Another relatively big company that uses PostgreSQL is Gitlab.

Re: MySQL for Developers

#107

Post by 9dev »

KronisLV wrote: post #76

It's really nice to see more content for MySQL/MariaDB still being made, since it feels like they are still good solutions for a whole variety of situations! While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough!

I wonder where that "MySQL is easier to scale" trope comes from. Have you ever tried to set up and operate a MySQL/MariaDB cluster? It's a horrible and brittle shitshow. Even if you get it running, there's no guarantee things don't just turn south at any given moment.

In Postgres, replication just... works.

Re: MySQL for Developers

#108

Post by KronisLV »

melvinmelih wrote: post #101
KronisLV wrote: post #82

Earlier quoted context omitted.

> What's PostgreSQL comparable list? I'm sure that others can comment on that, but in my experience PL/pgSQL is the killer feature that's hard to beat in PostgreSQL, for those cases where you want to store some amount of logic in the database itself (MySQL stored procedures feel a bit more limited). That said, it's not even the only procedural language that is available: https://www.postgresql.org/docs/current/xplang…

> where you want to store some amount of logic in the database itself If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Imagine having multiple teams updating that logic without any version control or visibility in what’s stored in pg.

> If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost.

Not sure about this.

On one hand, packages of reusable logic in the DB can be useful - like processing some data when you're selecting it, or doing common validations before inserting data, or even when trying to do some batch processing or reporting. On the other hand, I've worked on a large enterprise project where almost everything was done in the DB and Java was more or less used as a templating technology and to serve REST endpoints. Even with version controlled migrations, it was an absolute mess to work with, to debug and extend, even though the performance was great.

I've also talked with some people who still believe that the majority of logic should indeed be implemented as close to the source of the data as possible, as well as some other folks who don't feel using anything but their ORM of choice and prefer to abstract SQL away somewhat on the opposite end of the spectrum. Either approach can lead to issues, personally I'm somewhere in the middle - use ORMs if you please, map against views in the DB for when you want to select data in a non-trivial manner, consider some functions, or even stored procedures for batch processing, but don't get too trigger happy about it.

If you need lots of in-database processing for whatever reason, might as well use something that has a good procedural language, like PostgreSQL.

As for the critiques, the closest thing to a factual response I can give is by taking a look at the JetBrains developer survey: https://www.jetbrains.com/lp/devecosystem-2021/databases/

The reality seems to be that about half of respondents don't version their scripts, half don't debug stored procedures and the majority doesn't have tests in or against their database. It's not that you can't do these things, it's just that people choose not to. I'd expect a locally launched DB instance with all of the migrations versioned and automated, as well as data import/seeding to be the norm.

Re: MySQL for Developers

#109

Post by evanelias »

pritambarhate wrote: post #103
hu3 wrote: post #77

Earlier quoted context omitted.

> While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough I see this sentiment often here on HN. Something long the lines of "MySQL is enough for small apps but you want PotgreSQL for serious work." When in practice I find the opposite to be true. PotgreSQL is hard to scale and hard to upgrade when compared…

This kind of argument that XYZ company uses ABC software so it's also good for my project is not correct. Your requirements and their requirements are different. Also for many of the above companies, when they were started MySQL used to be the popular solution, so they started with it and stayed with it. The way Facebook or Uber uses MySQL is not how you will use it. Both PostgreSQL and MySQL are powerful databases a…

> The way Facebook or Uber uses MySQL is not how you will use it.

With large companies like Meta/Facebook, there is no singular "way" that the company uses a particular database. Larger companies typically have self-service generic managed database infrastructure, similar to RDS but internal. The workloads tend to be quite varied.

> (This is before AWS RDS, we had to set replication manually in those days) We had set up replication with

> MySQL 5.6. At that time MySQL replication had a few issues, and it used to break every few days.

Your chronology isn't right: AWS RDS was released in Oct 2009, and gained multi-AZ replication in May 2010. At this time, Postgres didn't even have built-in replication support at all yet; it first gained built-in streaming replication support in Postgres 9.0, released in Sept 2010.

Meanwhile MySQL 5.6 was released (GA) in Feb 2013, several years after RDS already existed.

In any case, if your replication was breaking every few days in MySQL 5.6, that was something specific to your environment / configuration / workload. What you're describing is definitely far from common. If a replication stream breaking this often was the typical experience with MySQL 5.6, at Facebook's scale we would have had a replication breakage every few seconds, and that definitively was not the case.

That's especially true with out-of-the-box software like WordPress. I can't imagine Automattic experienced frequent replication breakages with a normal WP workload, as this would have been hugely operationally problematic for their hosted wordpress.com product. Perhaps you had a misbehaving plugin performing non-deterministic DML or something like that?

That all said -- Postgres is an amazing database, and there are many good reasons to choose it; but as with all technical choices, there's a set of trade-offs to consider. For example, originally Postgres only supported physical replication, not logical replication, and this made upgrading to a new major version quite painful as compared to MySQL.

Re: MySQL for Developers

#110

Post by munbun »

KronisLV wrote: post #82
hu3 wrote: post #77

Earlier quoted context omitted.

> While I might look in the direction of PostgreSQL for more advanced in-database processing, for most CRUD apps the aforementioned two are going to be more than enough I see this sentiment often here on HN. Something long the lines of "MySQL is enough for small apps but you want PotgreSQL for serious work." When in practice I find the opposite to be true. PotgreSQL is hard to scale and hard to upgrade when compared…

> What's PostgreSQL comparable list? I'm sure that others can comment on that, but in my experience PL/pgSQL is the killer feature that's hard to beat in PostgreSQL, for those cases where you want to store some amount of logic in the database itself (MySQL stored procedures feel a bit more limited). That said, it's not even the only procedural language that is available: https://www.postgresql.org/docs/current/xplang…

of curiosity, can anyone share their testing strategy with pgSQL?
Post reply on HN