Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sgarland
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
31 ms
·
691.
▲
by
sgarland
1y ago
Agreed, though it’s also a monstrous effort to get devs to stop chucking everything into JSON, or my new favorite hell, serializing entire classes and storing them as a BLOB. It’s my fervent belief that we should revert to specialized roles
692.
▲
by
sgarland
1y ago
Tbf, my experience as a DBRE has been that most places should have a DB expert on staff, especially for Postgres. I’ve not used TigerData / Timescale, but IME there’s far more complexity to reason about and manage than people think.
693.
▲
by
sgarland
1y ago
Cassandra definitely isn’t dead, anyway. InfluxDB is a competitor to Timescale / TigerData, so that’s just a slam on them. I don’t think about MongoDB, other than of course the canonical video [0]. [0]: https://youtu.be/
694.
▲
by
sgarland
1y ago
The novelty aside (I don’t live in a service region for Waymo, so I can only try it if I fly out to SFO for work), I will happily pay a premium to have a consistent experience where I don’t have to potentially deal with an obnoxious driver.
695.
▲
by
sgarland
1y ago
> “…opportunities of this magnitude often come at a cost,” Wang wrote in the memo that he shared on X. “In this instance, that cost is my departure.” Gavin Belson would be proud. Or at least steal the quote; same thing, really.
696.
▲
by
sgarland
1y ago
Tangential: please do not use a phone number as a PK. Aside from the nightmare of normalizing them, there is zero guarantee that someone will keep the same number.
697.
▲
by
sgarland
1y ago
Altavista was the OG. I remember it being cantankerous and requiring you to specific in how you searched, but if you knew how to use it, it was unmatched. Until Google.
698.
▲
by
sgarland
1y ago
Accessibility aside, I don't see the appeal in this design. I find the current design quite pleasant and usable. Translucent 3D text sounds like teenage-me messing around in Photoshop in the early 2000s.
699.
▲
by
sgarland
1y ago
I get what you’re saying, but I also think the two are strongly correlated. If you have a website with excellent UX, but it’s massively bloated and has noticeably slow load times on anything less than a 1 Gbps connection, that’s making for
700.
▲
by
sgarland
1y ago
Is your goal to run your own services, or to understand them? The two are not mutually exclusive, and one can certainly understand containers, but the general vibe from this thread seems to be “I like containers because I don’t have to unde
701.
▲
by
sgarland
1y ago
Yes, because there are a stunning number of people within r/homelab who simply want to run Plex and torrent clients.
702.
▲
by
sgarland
1y ago
MySQL stores a copy of the PK in every secondary index, so it can start adding up quite a bit. I agree that the overall size of 10 billion rows would dwarf that, but since you're presumably doing some decent indexing on a table of that
703.
▲
by
sgarland
1y ago
> But if your natural key is the thing that changed you’d never know that airport x was renamed to airport y. Correct, which is why you need the addition of a DATETIME to indicate when that identifier is valid. > And when you renamed
704.
▲
by
sgarland
1y ago
> 2) This implies denormalization, which is rarely needed for performance, despite what so many believe. Now you’ve introduced referential integrity issues, and have taken a huge performance hit at scale. > 3) I mean, maybe don’t try
705.
▲
by
sgarland
1y ago
Not days necessarily, but I think quite a bit of time should be spent data modeling, yes. Before you’ve ever touched the keyboard, it’s very helpful to attempt to model the problem on paper or a whiteboard. You quickly find problems with yo
706.
▲
by
sgarland
1y ago
Now you have to specify whether or not it’s moved during queries (and what if it moves again?) There’s probably a more elegant way I’m not thinking of, but standard created_at and updated_at fields would work: if a given date is <= the m
707.
▲
by
sgarland
1y ago
The tradeoff you’re making is performance, sometimes a lot depending on your RDBMS and table size. For smaller tables, under 10,000,000 rows or so, you won’t really notice much, but in the hundreds of millions or billions, you definitely do
708.
▲
by
sgarland
1y ago
You don’t need all that; any candidate key (even natural) with the addition of a datetime would work. What was the definition of Airport X before Datetime Y? And after? Etc.
709.
▲
by
sgarland
1y ago
TIL that Klarna runs on Erlang.
710.
▲
by
sgarland
1y ago
Mostly on the administrative side. MySQL doesn’t have VACUUM to deal with, and that inevitably catches people by surprise in Postgres if they aren’t already experienced with it. Postgres is far more flexible and capable, but it requires a l
711.
▲
by
sgarland
1y ago
> Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet I have been extremely cynical about LLMs up until Claude 4. For the specific project I've been using it on, it'
712.
▲
by
sgarland
1y ago
The majority of any given point in the world’s oceans are deeper than the crush depth of any submarine. Submersibles, not so much (modulo Oceangate’s).
713.
▲
by
sgarland
1y ago
It works to a certain point, yes, but I daresay that the overwhelming majority of OLTP needs are in the <= TB range, not PB. OLAP is its own beast, though I'll also say that most modern tech companies' schema is hot garbage, fu
714.
▲
by
sgarland
1y ago
Fair enough, I didn't know it was that old.
715.
▲
by
sgarland
1y ago
> This doesn't affect availability - except insofar as unavailability might be caused by insufficient capacity, which is not the typical definition. I agree, but it seemed to me that GP was using it as such: "You cannot meaning
716.
▲
by
sgarland
1y ago
> You cannot meaningfully scale vertically to improve write availability Disagree. Even if you limit yourself to the cloud, r7i/r8g.48xl gets you 192 vCPU / 1.5 TiB RAM. If you really want to get silly, x2iedn.32xl is 128 vCPU
717.
▲
by
sgarland
1y ago
They’re referring to this: https://debezium.io/blog/2019/10/08/handling-unchanged-postg...
718.
▲
by
sgarland
1y ago
> The dream is a single data mesh presenting an SQL userland where I can write and join data from across the business with high throughput and low latency. That exists, and has for years: an extremely large DB loaded to the gills with RA
719.
▲
by
sgarland
1y ago
> but for some reason it doesn't apply to most people's databases. It’s because RDBMS effectively hasn’t changed in decades, and so requires fundamental knowledge of how computers work, and the ability to read dense technical d
720.
▲
by
sgarland
1y ago
> full-stack development today is fractally complex. There are MANY components that each might require hundreds of hours to understand This is precisely why I maintain that the entire notion of full stack engineering is flawed. It’s ab
More ›