AWS Acquires DuckLabs

Not that I like either actor in this particular play, but this isn't exactly an example of community oriented goodwill on Amazon's part.

* Cloudflare also seems to have gotten the same idea right with R2 Data Catalog

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) :)

The constraints are what let this happen. Unconstraining it might make a better generalist product but part of what you're opting into with DDB is the dumb "put an item in get an item out semantics" and the other side is knowing that it will still work if that volume increases dramatically.