Those are such noob mistakes.
No bigint OID, or worse, not UUIDv4, because even int64 will overflow, maybe not on their platform, but on a platform with millions of new inserts a day, despite being a large number, isn't future proof.
If anyone knows a better 128bit alternative to UUIDv4, please respond.

Side remark, that's what I was trying to tell the dgraph guy.
If you have an int64 ID for ALL your transactions and all your IDs it will eventually overflow. It's a single incrementing value for ALL actions. Inset a new record, new ID, retrieve this record, new ID etc.

Everything this guy writes about are newbie mistakes, stemming from a lack of "far sight", aka thinking 5 steps ahead.
Thinking 5 steps ahead is what I had to learn along the way, because if you don't you end up with problems like these.

What annoys me is that I'm actually seeking a job now and that I can't find one that fits my needs, despite being way past those Kinderkrankheiten (child diseases), because those jobs nowadays require you to be an AWS zealot, which I'm not.
I'm a follower of the holy church of K.I.S.S. keep it simple, stupid.
Simple and organized, the 2 key pillars of good design.
As simple as possible, but not more simple.
Thinking 5 steps ahead is the hard and time consuming part.

I know this article is about Ruby.
But as a Go zealot, which can handle 500 million visitors per month or over 5000 concurrent http1.1 connections on a 13 year old 4 core 32gb ram computer, I would NOT go AWS lambda and complicate my life and, most importantly, the development process or as I call it the solution delivery process.

This guy's problem is that he believed the hype, picked the wrong tool for the job and had no clue about infrastructure/operations.

There's a reason why Ruby isn't as popular as it was 10-15 years ago.
Performance matters.
The split between backend and frontend happened around 2013.
Having a classic website with low performing Ruby, that also has such a bad workflow, e.g. Blog, you can't start with Comment, you have to start with Blog, then Post, then Comment.
This is archaic.
With Go and ent I start wherever I want and I get ×100 the performance.
If I need to consume the data, if I don't care about SEO, I can write a SPA easily and the load is on the client.
If I need SEO I'm back to the scaling problem, but the Go backend won't be the one that needs scaling. And should you magically expect more than 500 million visitors per month, simply adding load balancing and doing this for the database as well would do the trick, BAM, you've now tripled the amount of backend requests you can handle.
Doing this for the SSR JS frontend is where it gets expensive.
So either try to static render with Svelte, if possible, to solve this problem and load balance or get locked into complex auto scaling cloud nonsense. And this is where it gets REALLY expensive.

Your Ruby on Rails app might be good enough for a PoC, but that's about it.
If you really expect large volumes of traffic, better pick a well performing language from the start and think about infrastructure.
And for the love of god, don't pick k8s. Because when shit hits the fan, you won't be able to debug it.
Keep it simple and transparent.
You can have your cake and eat it too.
Just think it through from the start to the end.