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

141–150 of 196 posts

Re: Databases in 2025: A Year in Review

#141

Post by lmwnshn »

znpy wrote: post #107
danielfalbo wrote: post #4

Maybe off-topic but, If you're not familiar with the CMU DB Group you might want to check out their eccentric teaching style [1]. I absolutely love their gangsta intros like [2] and pre-lecture dj sets like [3]. I also remember a video where he was lecturing with someone sleeping on the floor in the background for some reason. I can't find that video right now. Not too sure about the context or Andy's biography, I'll…

I can't understand if their "intro to database systems" is an introductory (undergrad) level course or some advanced course (as in, introduction to database (internals)). Anyone willing to clarify this? I'm quite weak at database stuff, i'd love to find some undergrad-level proper course to learn and catch up.

It is an undergrad course, though it is cross-listed for masters students as well. At CMU, the prerequisites chain looks like this: 15-122 (intro imperative programming, zero background assumed, taken by first semester CS undergrads) -> 15-213 (intro systems programming, typically taken by the end of the second year) -> 15-445 (intro to database systems, typically taken in the third or fourth year). So in theory, it's about one year of material away from zero experience.

Re: Databases in 2025: A Year in Review

#143

Post by dujuku »

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?

> Every metric I can find online says that MySQL/MariaDB is more popular than PostgreSQL

What are those metrics? If you're talking about things like db-engines rankings, those are heavily skewed by non-production workloads. For example, MySQL still being the database for Wordpress will forever have a high number of installations and developers using and asking StackOverflow questions. But when a new company or established company is deciding which new database to use for their custom application, MySQL is seldom in the running like it was 8-10 years ago.

Re: Databases in 2025: A Year in Review

#144

Post by esafak »

cryptica wrote: post #99

It's so weird how everyone nowadays is using Postgres. It's not like end users can see your database. It's disturbing how everyone is gravitating towards the same tools. This started happening since React and kept getting worse. Software development sucks nowadays. All technical decisions about which tools to use are made by people who don't have to use the tools. There is no nuance anymore. There's a blanket solutio…

What's wrong this postgres?

Re: Databases in 2025: A Year in Review

#145

Post by dang »

danielfalbo wrote: post #4

Maybe off-topic but, If you're not familiar with the CMU DB Group you might want to check out their eccentric teaching style [1]. I absolutely love their gangsta intros like [2] and pre-lecture dj sets like [3]. I also remember a video where he was lecturing with someone sleeping on the floor in the background for some reason. I can't find that video right now. Not too sure about the context or Andy's biography, I'll…

(I consed "https://" onto your links so they'd become clickable. Hope that's ok!)

Re: Databases in 2025: A Year in Review

#147

Post by refset »

quotemstr wrote: post #130
beders wrote: post #21

While the author mentions that he just doesn't have the time to look at all the databases, none of the reviews of the last few years mention immutable and/or bi-temporal databases. Which looks more like a blind spot to me honestly. This category of databases is just fantastic for industries like fintech. Two candidates are sticking out. https://xtdb.com/blog/launching-xtdb-v2 (2025) https://blog.datomic.com/2023/04/d…

XTDB addresses a real use-case. I wish we invested more in time series databases actually: there's a ton of potential in a GIS-style database, but 1D and oriented around regions on the timeline, not shapes in space. That said, it's kind of frustrating that XTDB has to be its own top-level database instead of a storage engine or plugin for another. XTDB's core competence is its approach to temporal row tagging and que…

> it's kind of frustrating that XTDB has to be its own top-level database instead of a storage engine or plugin for another. XTDB's core competence is its approach to temporal row tagging and querying. What part of this core competence requires a new SQL parser?

Many implementation options were considered before we embarked on v2, including building on Calcite. We opted to maximise flexibility over the long term (we have bigger ambitions beyond the bitemporal angle) and to keep non-Clojure/Kotlin dependencies to a minimum.

Re: Databases in 2025: A Year in Review

#148

Post by evanelias »

mdasen wrote: post #112
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?

Popularity can mean multiple things. Are we talking about how frequently a database is used or how frequently a database is chosen for new projects? MySQL will always be very popular because some very popular things use it like WordPress. It does feel like a lot of the momentum has shifted to PostgreSQL recently. You even see it in terms of what companies are choosing for compatibility. Google has a lot more MySQL wo…

> ClickHouse went with PostgreSQL.

What do you mean by this? AFAIK they added MySQL wire protocol compatibility long before they added Postgres. And meanwhile their cloud offering still doesn't support Postgres wire protocol today, but it does support MySQL wire protocol.

> Even search here on HN.

fwiw MySQL has been extremely unpopular on HN for a decade or more, even back when MySQL was a more common choice for startups. So there's a bit of a self-fulfilling prophecy where MySQL ecosystem folks mostly stopped submitting stories here because they never got enough upvotes to rank high enough to get eyeballs and discussion.

That all said, I do agree with your overall thesis.

Re: Databases in 2025: A Year in Review

#149

Post by cryptica »

da02 wrote: post #137
cryptica wrote: post #99

It's so weird how everyone nowadays is using Postgres. It's not like end users can see your database. It's disturbing how everyone is gravitating towards the same tools. This started happening since React and kept getting worse. Software development sucks nowadays. All technical decisions about which tools to use are made by people who don't have to use the tools. There is no nuance anymore. There's a blanket solutio…

Which alternatives to PostgreSQL would you like to see get more attention?

All of them. Nothing wrong with Postgres, I like Postgres. But the more alternatives the better. My favorite database is RethinkDB but officially, it's a dead project. Unofficially it's still pretty great.

Re: Databases in 2025: A Year in Review

#150

Post by laurencerowe »

WJW wrote: post #16
kopirgan wrote: post #12

Earlier quoted context omitted.

As a backend database that's not multi user, how many web connections that do writes can it realistically handle? Assuming writes are small say 100+ rows each? Any mitigation strategy for larger use cases? Thanks in advance!

Couple thousand simultaneous should be fine, depending on total system load, whether you're running on spinning disks or on SSDs, p50/99 latency demands and of course you'd need to enable the WAL pragma to allow simultaneous writes in the first place. Run an experiment to be sure about your specific situation.

You also need BEGIN CONCURRENT to allow simultaneous write transactions.

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

Post reply on HN