Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases in 2025: A Year in Review

cs.cmu.edu

Post reply on HN
Print view View original

161–170 of 196 posts

Re: Databases in 2025: A Year in Review

#161

Post by andersmurphy »

mtndew4brkfst wrote: post #155
andersmurphy wrote: post #142

With a trend towards immutable single writer databases MMAP seems like a massive win.

Andy is very critical of using mmap in database implementations.

Why? Sqlite and LMDB make fantastic use of it. For anyone doing a single writer db it's a no brainer. It does so much for you and it does it very well. All the things you don't have to implement because it does it for you:

- Reading the data from disk

- Concurrency between different threads reading the same data

- Caching and buffer management

- Eviction of pages from memory

- Playing nice with other processes in the machine

Why would you not leverage it? It's such a great fit for scaling reads.

Re: Databases in 2025: A Year in Review

#162

Post by _1tan »

apavlo wrote: post #76
jimmar wrote: post #66

> "The Dominance of PostgreSQL Continues" It seems like the author is more focused on database features than user base. Every metric I can find online says that MySQL/MariaDB is more popular than PostgreSQL. PostgreSQL seems "better" (more features, better standards compliance) but MySQL/MariaDB works fine for many people. Am I living in a bubble?

> Am I living in a bubble? There are rumblings that the MySQL project is rudderless after Oracle fired the team working on the open-source project in September 2025. Oracle is putting all its energy in its closed-source MySQL Heatwave product. There is a new company that is looking to take over leadership of open-source MySQL but I can't talk about them yet. The MariaDB Corporation financial problems have also spooke…

Percona I suppose?

Re: Databases in 2025: A Year in Review

#164

Post by alexpadula »

andersmurphy wrote: post #161
mtndew4brkfst wrote: post #155

Earlier quoted context omitted.

Andy is very critical of using mmap in database implementations.

Why? Sqlite and LMDB make fantastic use of it. For anyone doing a single writer db it's a no brainer. It does so much for you and it does it very well. All the things you don't have to implement because it does it for you: - Reading the data from disk - Concurrency between different threads reading the same data - Caching and buffer management - Eviction of pages from memory - Playing nice with other processes in the…

“ It's such a great fit for scaling reads.”

And losing them.

Re: Databases in 2025: A Year in Review

#165

Post by alexpadula »

spprashant wrote: post #68
jimmar wrote: post #66

> "The Dominance of PostgreSQL Continues" It seems like the author is more focused on database features than user base. Every metric I can find online says that MySQL/MariaDB is more popular than PostgreSQL. PostgreSQL seems "better" (more features, better standards compliance) but MySQL/MariaDB works fine for many people. Am I living in a bubble?

I think author is basing his observations on where the money is flowing. PostgreSQL adjacent startups and businesses are seeing a lot of investment.

Well yeah.

Re: Databases in 2025: A Year in Review

#166

Post by delaminator »

dietr1ch wrote: post #101
sanderjd wrote: post #92

Earlier quoted context omitted.

Aha! That makes so much sense. Thank you for this. Edit: Ah, right, the downside is that this is not going to have good olap query performance when interacting directly with the sqlite tables. So still necessary to copy out to duckdb tables (probably in batches) if this matters. Still seems very useful to me though.

Analytics is done in "batches" (daily, weekly) anyways, right? We know you can't get both, row and column orders at the same time, and that continuously maintaining both means duplication and ensuring you get the worst case from both worlds. Local, row-wise writing is the way to go for write performance. Column-oriented reads are the way to do analytics at scale. It seems alright to have a sync process that does the…

It's not just about row versus column. OLAPs are potentially denormalised as well, and sometimes pre-aggregation, such as rolling up by day, by customer.

If you really need to get performance you'll be building a star schema.

Re: Databases in 2025: A Year in Review

#167

Post by menaerus »

Sesse__ wrote: post #116
apavlo wrote: post #76

Earlier quoted context omitted.

> Am I living in a bubble? There are rumblings that the MySQL project is rudderless after Oracle fired the team working on the open-source project in September 2025. Oracle is putting all its energy in its closed-source MySQL Heatwave product. There is a new company that is looking to take over leadership of open-source MySQL but I can't talk about them yet. The MariaDB Corporation financial problems have also spooke…

> There are rumblings that the MySQL project is rudderless after Oracle fired the team working on the open-source project in September 2025. Not just the open-source project; 80%+ (depending a bit on when you start counting) of the MySQL team as a whole was let go, and the SVP in charge of MySQL was, eh, “moving to another part of the org to spend more time with his family”. There was never really a separate “MySQL C…

Wouldn't Oracle need those 80%+ devs if they wanted to shift their efforts into Heatwave? That percentage sounds too huge to me and if true I believe they won't be making any larger investments into Heatwave neither. There's several core teams in MySQL and if you let those people go ... I don't know, I am not sure what to make out of it but that Oracle is completely moving away from MySQL as a strategic component of their business.

Re: Databases in 2025: A Year in Review

#168

Post by kunley »

loxs wrote: post #30
kunley wrote: post #28

Earlier quoted context omitted.

What is a "local application"?

Funny how people used to ask "what is a cloud application", and now they ask "what is a local application" :-) Local as in "desktop application on the local machine" where you are the sole user.

That commenter's idea clearly wasn't about desktop application on a local machine. That is why I asked.

Re: Databases in 2025: A Year in Review

#169

Post by speedgoose »

shrx wrote: post #152
speedgoose wrote: post #8

Earlier quoted context omitted.

Not much happened I guess. Clickhouse has got an experimental time series engine : https://clickhouse.com/docs/engines/table-engines/special/ti...

QuestDB at least is gaining some popularity: https://questdb.com/ I was hoping to learn about some new potentially viable alternatives to InfluxDB, alas it seems I'll continue using it for now.

I'm running an experimental side project where I doing some kind of glue between various time-series APIs and storage engines.

For example it has an InfluxDB compatible ingestion API, so Telegraf can push its data to it or InfluxDB can replicate to it. It also has a Prometheus remote read and remote write API, so it's compatible with Prometheus.

The storage can be done in various systems, including ClickHouse, SQLite, DuckDB, TimescaleDB… I should try to include QuestDB.

Re: Databases in 2025: A Year in Review

#170

Post by WJW »

pixelesque wrote: post #51
WJW wrote: post #26

Earlier quoted context omitted.

SQlite as a database for web services had a little bit of a boom due to: 1. People gaining newfound appreciation of having the database on the same machine as the web server itself. The latency gains can be substantial and obviously there are some small cost savings too as you don't need a separate database server anymore. This does obviously limit you to a single web server, but single machines can have tons of core…

> SQLite has concurrent writes now Just to clarify: Unless I've missed something, this is only with WAL mode and concurrent reads at the same time as writes, I don't think it can handle multiple concurrent writes at the same time?

As I understand it, there can be concurrent writes as long as they don't touch the same data (the same file system pages, to be exact). Also, the actual COMMIT part is still serialized and you need to begin your transactions with BEGIN CONCURRENT. If two transactions do conflict, the later one will be forced to ROLLBACK although you can still try again. It is up to the application to do this.

See also https://www.sqlite.org/src/doc/begin-concurrent/doc/begin_co...

This type of limitation is exactly why I would recommend "normal" server-based databases like Postgres or MySQL for the vast majority of web backends.

Post reply on HN