It's a fair question!

My attempt at an answer: no, databases are not solved.

Specifically, different databases are better or worse for different use-cases.

For example, Postgres is a great "all around database" - you can use it for a lot of different things. As a "relational" database, it's really good if you have a table full of users, a table full of order, and you want to see all orders made by a user with ID=123. You need to answer questions like that a lot (eg every time someone on a website loads a page) and you need the answer fast (hundreds of miliseconds at most)

However, say your use-case is more like... you've got 100 billion rows of billing data ("joe was charged $123.45 on 2026-03-07 for a shirt, blue, size 11, brand foobar") in one table. You don't care much about joe, but you want to be able to find out how much was billed, total, in 2026-03 for blue shirts (or all year for brand foobar, or all time, for size 11). Postgres would struggle with data of that volume - you'd need a really big expensive database. A "columnar" database like duckdb (or clickhouse) might be able to answer those questions better.

Anyway, different databases are better/worse for:

- Large piles of data that you need to query in seconds

- Huge (petabytes) of data that you need to query in minutes, but can query in parallel

- Many related piles (like a standard relational database)

- Cases where you're mostly getting or retrieving single items (key-value stores)

- Huge piles of data that represent a long stream of events in time (time-series datbases)

- Piles of data that look and act more like files (object stores)

- When you need strict transactions

- When your need is very write-heavy

- When your need is very read-heavy

- and probably many others - I'm not even a huge data guy :)

So it all depends on your use-case. There are still cases that are not served well by any existing database - eg "filtering billions of rows, in milliseconds, by an arbitrary portion of several dozen very-high-cardinality columns" (to use an example that came up recently for me IRL) :)

This is a good summary. It's amazing that new database projects/products (whether it's open source or not) still spring up all the time.

Check this curated list of databases from Carnegie Mellon University: https://dbdb.io/

Just to add to this good explanation, a sufficiently large enough company (and even small successful companies) will eventually have a need for different DBs.