[from-nibly]

Feels like postgres is always the answer. I mean like there's gotta be some edge case somewhere where postgres just can't begin to compete with other more specialized database but I'd think that going from postgres to something else is much easier than the other way around.

[graealex]

It's not like PostgreSQL hasn't been in development for close to 30 years, covering basically every use case imaginable just through millions of deployments.

In addition, SQL in itself is a proven technology. The reality is that most problems you might think about solving with specialized databases (Big Data TM etc) could probably easily be solved with your run-of-the-mill RDBMS anyway, if more than five minutes are spent on designing the schema. It's extremely versatile, despite just being one layer above key-value storage.

[999900000999]

Depends.

If you want to fully embrace the vibe tables are difficult.

Even before LLMs, I was at a certain company that preferred MongoDB so we didn’t need migrations.

Sometimes you don’t care about data structure and you just want to toss something up there and worry about it later.

Postgres is the best answer if you have a solid team and you know what you’re doing.

If you want to ride solo and get something done fast, Firebase and its NoSQL cousins might be easier .

[pojzon]

I really enjoy this comment.

> Postgres is the best answer if you have a solid team and you know what you’re doing.

Not every type of data simply fits into relational model.

Example: time series data.

So depending on your model - pick your poison.

But for relational models, there is hardly anything better than postgres now.

It makes me happy coz I always rooted for the project from earily 2000s.

[SchemaLoad]

What situations do you encounter where you don't care about the structure of the data? The only ones I've ever encountered have been logging, where it's only purpose is to be manually text searchable, and something like OpenStreetMap where everything is just a key value store and the structure is loosely community defined.

As soon as you have a loosely defined object you can't access any specific keys which makes it useless for 99% of times you want to store and retrieve data.

[jacobsenscott]

PG requires a lot of expertise to keep running when you get to a billion rows or massive ingest. It can do it, but it doesn't just do it out of box running the defaults.

[graealex]

Hopefully at 1B records, you have a business model that allows you to spend some money on either hardware or talent to solve this problem.

[mdaniel]

There's a gist that shows up in these threads https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...

But while digging that up it seems there is one with more colors: https://postgresforeverything.com/

And one for the AI crowd https://github.com/dannybellion/postgres-is-all-you-need#pos...

[coolcase]

I hear MySQL can be better for some workloads?

[graealex]

Till about yesterday, MySQL was little more than a CSV file on wheels, and even current popularity is mostly driven by two decades of LAMP.

You can be sure that PostgreSQL will be applicable for any work load that MySQL can handle, but not necessarily the other way round, so if you actually have the freedom to make a choice, go with PostgreSQL.

In particular, because PostgreSQL has a lot more features, people imply that the other one, for the lack of those features and its associated complexity, must automatically be faster. Which isn't true, neither generally, nor in special cases, since the latter one can go either way - your particular query might just run 4x on PostgreSQL. There is also no universal approach to even benchmark performance, since every database and query will have completely different characteristics.

[JohnCClarke]

<Not intending to start a flamewar...> MySQL shines for simple OLTP. My PostgreSQL friends all have "paged at 3am to vacuum the database" war stories. I like simple and dumb for transactional data and MySQL delivers.