Comment by 0898
14 hours ago
I'm an idiot, and a lot of Hacker News goes over my head, but I still read it. Would anyone mind answering this question?
Are databases not a solved problem? Why are there lots of different databases? Why is one faster than the other? What's different between them?
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.
It's all about tradeoffs. Same reason there are so many kinds of wheeled transport and so many kinds of bridges.
There's no single set of requirements and desired properties that people have for databases.
What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
> What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
nothing prevents to build single database which would cover all such answers. Its engineering, funding and distribution problems: no-one built it yet.
Practicality and wisdom prevent trying to fill all the database niches with a single product.
Even if you did it, I'd be surprised if a single code base is optimal across the spectrum from resource constrained microcontrollers all the way up to IBM Z Series mainframes and everything in between; along with the full spectrum of persistence from in-memory MRU (or similar) caching to full two phase global consensus as well as optimistic eventual consistency.
There's just too much scope to be the best in class at everything, and even if somehow you did it, the maintenance cost of all the options would be huge.
Best you'll get is as computing continues to increase, the cost of using less than the best becomes more reasonable. There's a lot of database applications where any reasonable database works, and there's a lot of databases that are reasonable in wide application. That may well lead to fewer databases being available, but it's unlikely to converge down to a single database. Just as most engineering domains don't converge down to a single solution for all applications.
2 replies →
My very high level take:
Every tool is a trade off between effort to create vs power of the solution.
Effort is generally expensive so most things settle on some general purpose local maximum. If you had infinite effort available, you could build bespoke hardware and software from the ground up to solve every problem. It would be faster and more power efficient than any solution available today.
CPUs win out over integrated circuits because the same CPU can be used for ~every software problem, so by using a CPU you benefit from everyone pooling their efforts to improve the general purpose CPU rather than their own specific niche. But when you reach a certain scale/requirements it makes sense to do something more specific. This is one reason why we have standardized GPUs. Still general purpose but more specialized than a CPU. Or think about how Bitcoin mining moved to ASICs, because they need to do one specific thing as fast and as power efficiently as possible.
So for databases, when you get to specific scale and requirements the same kind of specialization starts to make sense. DuckDB or Clickhouse for analytical loads, TigerBeetle for high scale transactional stuff, etc. And that scale is aggregated across ~all software users, i.e. scale of analytical workloads being big enough to support analytical DBs.
Also as time goes on and industries develop the cost to develop specific solutions can go down.
There’s trade offs for performance, access patterns, throughput, latency, concurrency, workloads, rigor, type systems, extensibility… really every characteristic you could imagine.
It’s not a solved problem because each iteration of technology doesn’t just fix the mistakes of the past, it’s an evolution to solve the problems of the present.
DuckDB is really great. It's definitely the best tool for working with any type of tabular laptop-sized analytical data. You can do some of what DuckDB does with SQLite, but DuckDB is much more versatile and performant.
This is an enormously wide question but the quickest way to give you an idea would be rephrasing as:
"Are cars not a solved problem? Why are there lots of different cars? Why is one faster than the other? What's different between them?"
I think the best way to approach the subject in an easy to grasp way is to ask Gemini or another frontier AI to teach you the basics, they will do a surprisingly good job and they'll be able to react to your questions with INFINITE patience.
> Are databases not a solved problem?
What do you mean by solved problem? I don't own DuckDB (sqlite, postgresql, etc). If I think I can create something as good or better than DuckDB, should I give up doing so (and get filthy rich with an acquisition) because someone thinks databases are solved? Solved databases aren't mine.