Databases in 2024: A Year in Review

Post by [deleted] » Thu, Jan 02, 2025, 1:34 PM UTC

spprashant wrote: post #169

C-programmer wrote: post #109

Earlier quoted context omitted.

Inspect element on https://web.archive.org/web/20240827031455/https://ottertune... For more context: > I'm to sad to announce that @OtterTuneAI is officially dead. Our service is shutdown and we let everyone go today (1mo notice). I can't got into details of what happened but we got screwed over by a PE Postgres company on an acquisition offer. https://x.com/andy_pavlo/status/1801687420330770841

Oh wow, didnt know pe-postgres-company had any negative rep. Anyone care to explain how a company can screw another company via a acquisition offer?

Post by gregw2 » Thu, Jan 02, 2025, 2:00 PM UTC

josephg wrote: post #149

antirez wrote: post #86

Earlier quoted context omitted.

The examples I made are just a subset of the protection that this provides. Similarly you can't LRANGE a set type, and so forth. So this in general makes certain errors evident ASAP (command mismatch with the key type). This does not meant that Redis would not work having generic LEN, INSERT, RANGE commands. But such commands would end also having type-specific options, that I have the feeling is not very clean. Anyw…

Eh. What people are really arguing about here is redis’s type system. Redis’s approach has some pros and some cons. I think dismissing redis’s approach out of hand for its choices is too simple a treatment. Most sql databases (like Postgres) require all types to be declared once, and then they do type checking on mutation. In that sense, sql is like a static language like C. But weirdly, the results returned from a s…

Post by zzzeek » Thu, Jan 02, 2025, 3:13 PM UTC

thayne wrote: post #144

zzzeek wrote: post #79

Earlier quoted context omitted.

> You totally miss that Redis is more like a remote interpreter with a DSL that manipulates data structures stored at global variables (keys): I think he makes the point that these "global variables" are dynamically typed; you can have "listX" and then write a non-list into that same name; statically typed systems would not allow this. He makes the fairly non-controversial point that a statically typed system (SQL, o…

> you can have "listX" and then write a non-list into that same name; statically typed systems would not allow this Well, that depends. In most SQL databases there are many cases where supplying the wrong type of value will implicitly convert to the expected type, often in unexpected ways that can result in subtle bugs.

Post by nojito » Thu, Jan 02, 2025, 3:18 PM UTC

syspec wrote: post #154

lvl155 wrote: post #52

I highly recommend their Youtube series on databases. They have great guest speakers.

Link?

Post by atombender » Thu, Jan 02, 2025, 4:48 PM UTC

Icathian wrote: post #186

atombender wrote: post #41

The article mentions Greenplum, but it's worth noting that when the code was closed, several of the original developers created an open-source fork, Cloudberry, which seems to be thriving. Cloudberry was accepted into the Apache project this year, and has synced with Postgres 14, whereas the closed-source Greenplum is still stuck on Postgres 12. The architecture is quite ancient at this point, but I'm not sure it's c…

This is mostly correct, but it's worth mentioning that cloudberry substantially predates Greenplum going closed source. It just got quite a boost from that change happening. Different dev team too, afaik none of the original Greenplum team was involved with Cloudberry until very recently. Also, Greenplum 7 tracks postgres 14. Which is still old at this point, but not so bad as 12.... I also don't think I'd call the a…