4 ms·

Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with si

Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which can be a hard problem (it was, the last time I used Postgres). For full text search, I once worked on a project that considered several alternatives for this, including Postgres. Manticore Search was finally chosen because it was more performant, with better search results.

fabian2k 2mo ago
If you run a single application, or a few instances of the same application, you don't need an external pool and most frameworks have an internal connection pool anyway. Not sure if I'm missing anything here, but if I want case-insensitive search I simply create an index on lower(column) and use that to query. VACUUM is something you need to pay attention to at scale. And at that point you need to know your DB anyway and tune it. For smaller applications (and I don't mean only toy applications) it usually isn't an issue.
- tux3 2mo ago
  >if I want case-insensitive search I simply create an index on lower(column) and use that to query Or even pg_trgm trigram indexes, which are case-insensitive by default and support similarity search to accept typos and misspellings.
  - sgarland 2mo ago
    They're also massive.
andriy_koval 2mo ago
> * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. is there a strong evidence you even need client side connection pool at all? What is the purpose? The limitation is that you have many clients with connection pools, they hold internal PG connection without allowing it to be reused by other clients..
sgarland 2mo ago
> case-insensitive Tbf you can also achieve this in Postgres, it's just not present by default. From the docs [0]: CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1'); 0: https://www.postgresql.org/docs/current/collation.html https://www.postgresql.org/docs/current/collation.html

fabian2k 2mo ago

If you run a single application, or a few instances of the same application, you don't need an external pool and most frameworks have an internal connection pool anyway. Not sure if I'm missing anything here, but if I want case-insensitive search I simply create an index on lower(column) and use that to query. VACUUM is something you need to pay attention to at scale. And at that point you need to know your DB anyway and tune it. For smaller applications (and I don't mean only toy applications) it usually isn't an issue.

tux3 2mo ago
>if I want case-insensitive search I simply create an index on lower(column) and use that to query Or even pg_trgm trigram indexes, which are case-insensitive by default and support similarity search to accept typos and misspellings.
- sgarland 2mo ago
  They're also massive.

andriy_koval 2mo ago

> * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. is there a strong evidence you even need client side connection pool at all? What is the purpose? The limitation is that you have many clients with connection pools, they hold internal PG connection without allowing it to be reused by other clients..

sgarland 2mo ago

> case-insensitive Tbf you can also achieve this in Postgres, it's just not present by default. From the docs [0]: CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1'); 0: https://www.postgresql.org/docs/current/collation.html https://www.postgresql.org/docs/current/collation.html