Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A database for 2022

tailscale.com

Post reply on HN
Print view View original

181–190 of 336 posts

Re: A database for 2022

#181

Post by jldugger »

tptacek wrote: post #87

This thread has (at least at the moment) serious Bob Martin Sudoku Solver energy to it. Tailscale has solved an infamously complicated problem using, for the most part, simple tools. They're not just successful; they're remarkably successful, spookily successful, upsettingly successful. Consider whether the secret sauce here might not be au courant database choices, but rather something much harder for random teams t…

> serious Bob Martin Sudoku Solver energy to it

You mean Ron Jeffries?

Re: A database for 2022

#182

Post by devmunchies »

nrr wrote: post #171
jrockway wrote: post #162

Earlier quoted context omitted.

Yeah. Maybe people are overestimating how expensive this kind of change is. We can all imagine being part of a larger org, where one day an All Hands appears on your calendar, and some exec you've never heard of proclaims the beginning of a 2 year multi-team database migration project. So now instead of making nifty software, you are just in 40 hours of meetings a week fighting over small details on this migration no…

I have the odd feeling that this kind of overestimation comes from the experience that folks tend to have in writing more traditional N-tier applications, especially post-Rails. A certain kind of database-first, ORM-first design philosophy really took hold after that, and it became somewhat common to see incredulity in response to telling someone that you weren't using something like MySQL or Postgres in production.…

When I used dynamic languages (Node.js and Ruby) I leaned on the database as the structural source of truth for types—it was the rigor a successful project needs.

But as I’ve been using only statically typed languages the last few years (on the backend), I’ve moved to designing the domains in the code, like you said.

Re: A database for 2022

#183

Post by tptacek »

jldugger wrote: post #181
tptacek wrote: post #87

This thread has (at least at the moment) serious Bob Martin Sudoku Solver energy to it. Tailscale has solved an infamously complicated problem using, for the most part, simple tools. They're not just successful; they're remarkably successful, spookily successful, upsettingly successful. Consider whether the secret sauce here might not be au courant database choices, but rather something much harder for random teams t…

> serious Bob Martin Sudoku Solver energy to it You mean Ron Jeffries?

I might!

Re: A database for 2022

#185

Post by rablackburn »

ramraj07 wrote: post #167
rablackburn wrote: post #100

I loved this article, despite the negativity. A discussion that keeps recurring on HN is how you can get a lot done with simple, boring solutions. This is a perfect example of that in practice. What’s the simplest thing that’ll work? Do that, monitor the solution, and when you start hitting a limitation reevaluate what the next appropriate solution is. There are plenty of comments here deriding this as insanity when…

The question is, is this the simple solution? Perhaps I and others have been spoiled by cloud offerings but having set up RDS once and never having to worry much about the db architecture after that for years as we scale has maybe spoiled us.

I’ll be honest and admit my own bias to cheaper, self-managed tooling. I’ll admit that RDS definitely meets the criteria of simple.

From what I understand RDS works great and you’re happy to pay what feels like the tiny cost…right up until it doesn’t anymore.

You’re paying Amazon a premium for them to manage the tedious stuff. But sometimes dealing with the tedious is what teaches you how the stack works and makes you jmuch more prepared to solve those more complex problems down the road.

The uncomfortable fact is businesses finding themselves in situations where they experience vendor-lock-in just because they’ve let their capability wither away.

Clearly David’s point about avoiding MySQL and PostgreSQL due to fears of “vendor lock-in” resonates with me, even if I personally think that’s not quite where the threat is.

…for Postgres anyway. I’ve heard enough stories that I never want to touch an oracle product in my career.

Re: A database for 2022

#187

Post by techdragon »

0des wrote: post #152
reilly3000 wrote: post #146

Earlier quoted context omitted.

If anything, this ^^^ is how you win the long game. History will surface itself when you make assertions. Gracefully revocability scales.

At least he's not the Dropbox guy

This and the “no Wi-Fi less space than a Nomad” comments on slash dot about the iPod are my favourite examples of “you don’t get consumers” comments.

Re: A database for 2022

#188

Post by hashhar »

tptacek wrote: post #172
ransom1538 wrote: post #170

Earlier quoted context omitted.

One of the largest forums online in 2003 was was ezboard. A billion page views per month. Back then - insane - well that was beyond insane. I started work there as a young idiot. "What db you guys using, mysql?...." long pause... "We use a file system." I dug in. Yep. A fucking file system. Files allowed: simple backups, impossible speed, obvious cache systems, partitioning. Later on i met the roomate of the author o…

The guy who wrote memcache is on this thread, I think?

And he even works at Tailscale now.

Re: A database for 2022

#190

Post by IshKebab »

tptacek wrote: post #144
jeffffff wrote: post #119

Earlier quoted context omitted.

they've already had to migrate twice due to questionable technology decisions. having to migrate again due to needing to change cloud providers seems a lot less likely than having to migrate again because their outside the box technology choice didn't pan out.

"Questionable technology decisions". You're trying to dunk, but I don't think you understand where the hoop is. Their technology decisions have panned out Tailscale well . We should all be so fortunate. This isn't Twitter with the "fail whale"; the only reason you know about any of this stuff is because they wrote about it. They ran their entire service with a JSON file backend for 18 months, and switched from it to…

They're not questionable because they didn't work, they're questionable because they were so difficult to run that they had to migrate twice.

You could absolutely run a web site using Brainfuck without any failures or any customers realising it. Doesn't mean it's not a questionable decision!

Post reply on HN