Live data from Hacker News

Databases in 2024: A Year in Review

cs.cmu.edu

121–130 of 220 posts

Re: Databases in 2024: A Year in Review

#121

I think one thing Andy misses about why people were pissed about Elastic and Redis but not as many for MongoDB and some other is their license and size of Contributors Community. When original license is as restricted as AGPL it is unlikely there is much of embedded use... so less people are impacted in truly catastrophic way Also if there is no contributor community to speak of... who is going to do the fork ? I put…

RE ScyllaDB, there will absolutely be no fork and it’s very unlikely they have ever had a meaningful contribution to Scylla OSS (which is not changing, just going to bit rot and the enterprise version which was closed source was moved to source available). The reasoning being the bar is very high for contributions. It’s C++ 20/23 without virtual memory and a userland cooperative thread per core scheduler (this is the underlying seastar framework). The skills needed to do anything meaningful here is very high and I don’t see the motivation behind it as I would expect people having feature requests would be customers, have an easier time extending Cassandra or the feature would be available in the Enterprise version.

Re: Databases in 2024: A Year in Review

#122
post #45

Earlier quoted context omitted.

Are people choosing SQL Server independently of the Microsoft ecosystem? My understating is that you typically use it because you’re forced to choose a MS product.

SQL Server is a terrific product. And I detest most things Microsoft.

Except when you need to scale.

Re: Databases in 2024: A Year in Review

#123
post #104
post #94

Earlier quoted context omitted.

Agreed with the other person. It's a great database. I wouldn't choose it for a startup over Postgres, but it is extremely capable.

I would use it if it supported backup/restore over unix pipes / ssh.

If it supports backup to a file, you can have it write to a named pipe and from there to wherever.

I used this hack for backing up Oracle 30 years ago.

Something like 'mknod p backup.dmp; oradump .... file=backup; dd if=backup.dmp | ssh othermachine receiver-process'

Re: Databases in 2024: A Year in Review

#124

Earlier quoted context omitted.

How do they enforce the ban? Do universities have non-compete clauses for PhD students?

I assume it's not that kind of ban, but more like he'll recommend his students to avoid the company.

Pretty much. Plus, from my perspective - if a company is willing to screw over your advisor/professor, you know that they won't hesitate to screw you over too.

Re: Databases in 2024: A Year in Review

#125

Weird how SQL Server and its Azure variants gets no mention. It dominates in certain sectors. DBEngines ranks it third most popular overall https://db-engines.com/en/ranking

SRE who deals with some .Net stuff that uses MSSQL but is converting to MySQL. so I feel somewhat qualified to talk about MSSQL. TL;DR: Nothing interesting going on. There is nothing to talk about here. It's boring database engine that powers boring business applications. It's pretty efficient and can scale vertically pretty well. With state of modern hardware, that vertical limit is high enough most people won't enc…

It's the Linux-isation of the db space. Once Linux was good enough for enterprise work, it massively reduced demand for Solaris/HP-UX/AIX/WindowsNT.

Same thing is happening now to Postgres vs enterprisey DBs.

Re: Databases in 2024: A Year in Review

#126

Redis is slow?

Yes. 1. It is single-threaded, which severely limits throughput for a single instance. 2. All communication must go over a socket, which severely impacts latency for use cases where it could otherwise run in-process.

What is the better alternative?

Re: Databases in 2024: A Year in Review

#127

Earlier quoted context omitted.

Yes. 1. It is single-threaded, which severely limits throughput for a single instance. 2. All communication must go over a socket, which severely impacts latency for use cases where it could otherwise run in-process.

What is the better alternative?

depends on your use case. also, for most redis is fast enough which is why it is wildly popular

Re: Databases in 2024: A Year in Review

#128

This take screams more than a technical criticism but of something personal. “I'll be blunt: I don't care for Redis. It is slow, it has fake transactions, and its query syntax is a freakshow. Our experiments at CMU found Dragonfly to have much more impressive performance numbers (even with a single CPU core). In my database course, I use the Redis query language as an example of what not to do.” (From the article) Of…

[deleted]

Re: Databases in 2024: A Year in Review

#129
post #48
post #14

Wow, the reasons why Redis commands API suck in Andy's video (linked in the post) are the weakest ever. It is possible to make a case against the Redis API (I would not agree of course but... it's totally legitimate), but you gotta have stronger arguments than those, particularly if you are a teacher of some kind. Especially: you need to be somewhat fluent in Redis and how developers use Redis in order to understand…

> Andy's video (linked in the post) Is there a "to long didnt watch" summary any one knows of? I hate videos, but am curious lol

same same

Re: Databases in 2024: A Year in Review

#130

Redis is slow?

Slow is relative, but you might want to check out Garnet [0] for ideas. Previous discussion at [1], current compatibility at [2].

[0] https://www.microsoft.com/en-us/research/blog/introducing-ga...

[1] https://news.ycombinator.com/item?id=39752504

[2] https://microsoft.github.io/garnet/docs/commands/api-compati...

Post reply on HN