> Postgres was a "it exists" database back in the early 2000's.
If we're really nitpicking it's not saying Postgres is the most popular database since the early 2000's. If you base it of off install counts as the metric, I would assume the statement is true since I'd think it's either Postgres or MySQL today.
I'm still trying to understand the scaling story better. When we say serverless it mentions automatically scaling when it detects some sense of resource pressure. If I have a "hot tenant-database", does that mean this shard will be scaled automatically without impact to existing queries? Or would there be some "blip". I suppose it's unavoidable in edge cases but curious about the regular ones as well.
It's an incredibly cool CX you have here with the automated query routing/tenancy story though, looking forward to what happens in this space.
> Rebuilding a cluster from the last-known-good backup should not take that long
It's not even clear if that's the right thing to do as a service provider.
Let's say you host a database on some database service, and the entire host is lost. I don't think you want the service provider to restore automatically from the last backup because it makes assumptions about what data loss you're tolerant to. If it just works from the last backup, suddenly you're potentially missing a day of transactions that you thought were there that magically disappears as opposed to knowing they disappeared from a hard break.
Sure, but isn't this more about risk tolerance at this point and how much your customers care about? Where the responsibility should be on customer's end. Running on EBS/RDS doesn't guarantee you won't lose data. If you care about it, you enable backups and test recovery.
Just because some customers are less fault tolerant than others, doesn't mean we shouldn't offer those options where people don't have the same requirements or are willing to work around it.
That at least doesn't work at all in my situation. I'm based in Seattle and I collaborate regularly with folks in probably 3-4 other geographic locations, ironically no one actually in Seattle.
If anything getting the video conferencing to work in a meeting room is more of a hassle/friction and a poorer experience when you still have to accommodate someone remote.
For the record I'd prefer a work environment that's closer to maybe 1-2 times a month in the office.
> Most developers are self learners (that's how most people learn to code anyway)
I don't think that's true. If you poll the vast majority of people in intro to CS class, most people never coded before. I recall it being a small minority at least back when I was in school (> 10 years ago).
There's also stats comparing before WFH and after of how long long it takes someone to onboard properly/be productive (forget the exact stat/KPI, mix of survey/commit stats?) and it's extended by a few months. Now that might be due to bad on-boarding since it wasn't a remote-first, but if that still exists years later it is interesting
> People collaborate better in person: Bullshit, a lot of developers collaborate better through text
Agree with that. I really wish we would write better docs and have more of an async setup
I do genuinely think there's aspect/learning that is lost/slower in the last few years, but that might be because we haven't really thought about accepting "remote-first" and trying to shoehorn what we already had into WFH model.
> Postgres was a "it exists" database back in the early 2000's.
If we're really nitpicking it's not saying Postgres is the most popular database since the early 2000's. If you base it of off install counts as the metric, I would assume the statement is true since I'd think it's either Postgres or MySQL today.