What is go-to solution for Postgres to have data encrypted on disk? I think that MySQL is more popular in enterprise as there's transparent encryption in enterprise version that's single click.
Ask HN: It's 2023, how do you choose between MySQL and Postgres?
291–300 of 366 posts
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#292Earlier quoted context omitted.
I forget if there's an equivalent for the first one, but from psql there is a translation of mysql's "DESC table" as "\d table", and the rest are: \dt \l SELECT * FROM pg_stat_activity;
> I forget if there's an equivalent for the first one Not really; PostgreSQL doesn't store the original query, so you'll need to re-create it from pg_class, pg_attribute, and all of that (which is really what \d and such in psql do). The easiest way is probably pg_dump, but it's best to just get used to \-commands because it's really just the same thing.
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#293Earlier quoted context omitted.
I mean, for most mature ecosystems / technology stacks I think the “no one size fits all, just strategic design trade-offs” theory largely holds true as an objectively accurate account of the “choosing the best tool“ situation …. but IMO, I think it’s worth noting that occasionally, some rare unique and functionally superlative technology comes along that in practice transcends every alternative from the onset and in…
> something maybe like Git, most immediately comes to mind, as an example of the de-facto standard for distributed VCS basically since … 1995 when Linus decided to create it? hot take. might be the most popular, maybe even by a large margin, but I think you'll find a good chunk of people who have actually tried different VCSs don't think it's the best.
I suspect the die-hard proponents of Mercurial, or SVN, or whatever else, these few pagan heretics that might exist out there wherever they’re hiding, have found themselves in a camp different to the Git standard likely on the basis of electing to be intentionally contrarian / anti-normative as the general catalyst, and rather not, as a function of struggling with Git to the point of being so disillusioned they call it quits and head out looking for greener pastures. I think in practice the most common result of encountering problems with Git is, fix the problems. And functionally I think that’s resulted only in furthering it’s supremacy over alternatives, despite there existing a handful of cultish weirdos who are _really_ into Mercurial and prefer not to fux with Git as a personal lifestyle choice haha)
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#294Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…
Imagine when you actually need any of the features that PostgreSQL provides like pub/sub, logical replication, JSONB etc. With MySQL you might have to hack a solution that is much more complex or you have to set up an entirely separate tool. What I find nice with PostgreSQL is that for simple cases you can get away without a dedicated key/value store or a queue or a full text search engine. You can do a lot of these kinds of tasks with just a single database.
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#295Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…
> It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. Imagine when you actually need any of the features that PostgreSQL provides like pub/sub, logical replication, JSONB etc. With MySQL you might have to hack a solution that is much more complex or you have to set up an entirely separate tool. What I find nice with PostgreSQL is that for simple case…
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#296We have over the years compared the rate of production incidents Postgres vs MySQL. It's roughly 1:10 (MySQL has around 10 times more production incidents than Postgres).
You may consider this anecdotal evidence, but numbers managed here are quite significant.
The gist is that Postgres is not perfect nor free from required maintenance and occasional production incidents. But for the most part, it does the job. MySQL too, but with (at least from an operational perspective) many more nuances.
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#297piggybacking on this: does anyone know a Postgres alternative to PlanetScale?
CockroachDB is PostgreSQL compatible and is distributed SQL supporting single-region, multi-region and multi-cloud deployments.
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#298Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#299I have a production app on MySql, but that was before docker and MySQL was a fair bit easier to setup then. That was my need at the time.
Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?
#300Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…
I would disagree on maintenance being simpler. I have never had Postgres randomly munge a table and require me to run a command to fix it.
Not saying it can't happen, but I don't think it's a common occurrence.