I thought this HN post on databases might be relevant to the future of coding: https://kevin.burke.dev/kevin/reddits-database-has-two-tables/

Hmm seems to be from 2010? This structure seems to make sense for smaller teams / workloads

HN thread for posterity: https://news.ycombinator.com/item?id=32407873

At the other end of scale, the (2013) article about how FB built their graph db on MySQL also hit HN today https://engineering.fb.com/2013/06/25/core-data/tao-the-power-of-the-graph/

The conclusion I take from this is that the RDBMS they used wasn't geared towards their use case back then, and they had to forego most of the advantages of the RDBMS as a result. It tells me that we need better RDBMS, and I will say that it has become a lot better in the years since then.

For example @Joakim Ahnfelt-Rønne?

@wtaysom For example, I just - as a test - did

alter table (redacted) add column foobar bigint;

in a table with billions of rows in Postgres, and it was instant. It's worth noting that schema changes are also transactional in Postgres.

My personal pain point is wanting to have multiple versions of the redacted table that I can modify independently and then merge later. I have managed to do this in Postgres, but it was not pretty.

That would be very handy for development.

They basically re-invented the {Entity,Attribute,Value}/{Subject,Predicate,Object} style one sees in datalog/semantic web databases, but calling the Entity/Subject a "thing". Hopefully they kept improving it after 2010 until they realized they actually want triplicate indexing to allow good performance with complete query flexibility.