it is like old school with time sharing systems -- you gotta be efficient when your turn comes up in the lab on the punch card and mainframes... instead of the mindless and endless trial-n-error hacking we are used to these days?
Except if you're waiting for your turn to come up so you can vibe code, you're combining mindless trial-and-error hacking with a deranged sleep schedule. It's the worst of both worlds.
Sure why not -- I mean redshift is a cluster of Postgres databases as well. What you don't get is scale -- so its fine for a small data warehouse (in which case is it really a data warehouse...)
I am not sure I agree with the general idea that Postgres can't or even--albeit a bit less strongly--that it is hard to scale. Even in 2008 people were running petabyte-scale warehouses using Postgres:
Since 2008 improvements in parallel query execution (and numerous other improvements) in the core project plus the availability of forks/extensions which abstract and/or modify various bits for improving scalability (see Citus and Timescale) it's never been easier to scale Postgres to some truly staggering heights.
While I wouldn't want to speak in absolutes, there are very few applications where I think Postgres wouldn't be a viable choice as a data warehouse.
Emphasis on warehouse as I wouldn't want to suggest Postgres as an ideal candidate to be a data lake. The difference between them for me being whether or not the data is structured/processed. Similar in definition to this article:
Personally, I have experience scaling core PostgreSQL (9.4) to handle ingestion of monitoring data for web servers to the tune of 2-3 terabytes a day. Not the grandest of scales, but enough to have seen a few bumps along the way...and, for what it's worth, I think it is surprisingly easy to scale.
I wouldn't want to sign up to scale Postgres to handle exabyte data loads, but single digit petabytes? Sure.
This is a good story for all to realize -- you CAN talk about your OWN pay to anyone you want. Every employer I know has tried to say "you can't do that" or "its in your contract" and I would rebuff and say the contract is illegal/non-binding as it goes against labor laws (in the US as per various labor laws and an executive order as recently as Obama). I get really annoyed w/ HR in firms -- their goal is to stop information from being shared to control things. On the flip side I do not agree that just because your colleague makes X that you deserve X. Pay never consistent and I have no problem with that part given we aren't clones of each other either.
Is that a US think? I've worked for employers in several European countries and have never heard an employer telling me not to discuss pay. Once a manager told me not to tell everyone about a pay raise as it was out of schedule and he didn't want lengthy discussions with other employees. But that was his personal request, not a request by HR. If I had wanted to discuss it I could've done without consequences, he made that clear as well.
It's still unusual to discuss pay in many companies but not because the employer prohibits it.
Is salary negation a common thing in Europe? Because in the US, it’s pervasive if you’re salaried (not hourly). The problem then becomes: if I negotiated, say, $75k/year, but my equally skilled coworker negotiated $85k/year, it doesn’t look good on the company. So the company just pushes you to not share at all. And it’s worked.
yes salary is negotiable in Europe but mostly within a range depending on your level (which is usually not transparent, you don't know the ranges).
people mostly avoid salary discussion because of cultural reasons I guess, but never due to the employer, I can't imagine HR telling someone to not discuss their salary.
Hmm i think the pace of changes has made software break more, but unit tests and integration tests are an improvement. But I agree writing unit tests takes a hella lotta time, not sure if a sr eng should be doing that 1/2 the time
