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

101–110 of 336 posts

Re: A database for 2022

#101

Post by jbmsf »

tptacek wrote: post #46
musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Do you want to know how popular systems are actually built, from the inside, or do you want carefully groomed triumphal announcements of new, perfectly-formed features? I struggle with this a lot in my writing too, but I've drawn a conclusion I'm sticking with: it's better to relay what the team is actually doing, "warts" and all. We ranked on HN a few weeks ago with a post about user-mode WireGuard that was basicall…

I love Tailscale and it's true that I am not suffering from stability problems with its database choices.

But, I do have challenges working with their ACL structure -- which is backed by their database -- and specifically would love to be able to update users/groups separately from tag groups and both of those separately from ACL rules and I can't help but wonder if the fact that this feature doesn't exist relates to the fact that the database doesn't normalize these concepts into separate "tables" separated by "foreign keys".

Re: A database for 2022

#102

Post by dimgl »

tptacek wrote: post #46
musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Do you want to know how popular systems are actually built, from the inside, or do you want carefully groomed triumphal announcements of new, perfectly-formed features? I struggle with this a lot in my writing too, but I've drawn a conclusion I'm sticking with: it's better to relay what the team is actually doing, "warts" and all. We ranked on HN a few weeks ago with a post about user-mode WireGuard that was basicall…

I have nothing to add to this discussion, but I wanted to add that I love this comment. Sometimes we have to take a step back and really think about why we're making all of these choices and picking certain tools for a job.

Re: A database for 2022

#103

Post by acrispino »

nosefrog wrote: post #53

There's a lot of negativity here, so I just wanted to comment that I think the approach Tailscale is taking with sqlite is pretty neat. MySQL and Postgres are both pretty complicated, so gluing together two simpler systems, sqlite and litestream, sounds appealing, and I'm interested to hear how it turns out in the long run.

Been reading HN a while and it's disappointing to see this much unjustified negativity.

Re: A database for 2022

#104

Post by tapirl »

Xeoncross wrote: post #3
infogulch wrote: post #2

They're using litestream [1] to replicate a SQLite database, which streams additions to the SQLite WAL file to object storage and can replay it back. This is fairly hands-off from SQLite's perspective. There's also the SQLite Session Extension [2] that is a built-in way to support generating and applying "patches". I'm curious how these tools will mature, it seems like a good match for microservices. [1]: https://git…

The litestream project was created by https://github.com/benbjohnson who wrote https://github.com/boltdb/bolt (a key value store) which has been instrumental (from my point of view) in the Go community as one of the original choices for an embedded database as it was not only fast, but had transactions with stable snapshots. It was used by https://github.com/blevesearch/bleve , https://github.com/etcd-io/etcd , and n…

It is strange that, although https://github.com/syndtr/goleveldb is used in the go-ethereum project for years, it is mentioned rarely (comparing to other go dbs).

Re: A database for 2022

#105

Post by ignoramous »

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…

> People aren’t perfect, not every engineer comes fully-formed grokking the industry’s best solutions and their trade offs.

The thing is, David Crawshaw is being extremely honest and humble here in admitting their shortcomings and how they're learning from it... but an entire troupe of Silicon Valley engs seem to have lost sleep over it, for reasons beyond me.

Re: A database for 2022

#106

Post by 0xFFFE »

Totally off topic. I am not an UI/UX designer but why can't the page scale to the size of the screen? Sure I could ctrl/cmd++ but is it hard to detect the screen size? Genuine question, not trying to be condescending.

Re: A database for 2022

#107

Post by [deleted] »

0xFFFE wrote: post #106

Totally off topic. I am not an UI/UX designer but why can't the page scale to the size of the screen? Sure I could ctrl/cmd++ but is it hard to detect the screen size? Genuine question, not trying to be condescending.

[deleted]

Re: A database for 2022

#108

Post by dastbe »

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…

nobody goes to these restaurants for their omelets, though at the same time nobody should care how tailscale actually implements things so long as it works well.

imo they’re not solving a notoriously hard problem, they’re realizing that they have the tiniest version of this problem (and that will most likely continue to be true). when that’s the case and you want to prioritize stuff that moves the needle like dev velocity, why do anything less simple? getting hung up on building scalable solutions far beyond what you need is somewhere between a fool and a big co employees game. far too often people introduce complexity way before it’s needed, and that almost always slows down your devs ability to actually fix bugs and make the product more reliable.

Re: A database for 2022

#109

Post by odonnellryan »

endisneigh wrote: post #7

I'm so desperate for a SQL database where I can just put it on a bunch of commodity hardware via Docker, connect them up and never worry about this again. Ideally it'd monitor my queries and create indexes for me. pleeeeeeaaaaaaaaaaaassssseeeeeeeeee /dream FoundationDB is similar but you have to do so much yourself. It's more or less what I'm describing for a key value store though. Not sure why it's not more popular…

You probably don't really want that. But not in the way that people didn't want WoW classic.

Re: A database for 2022

#110

Post by tapirl »

database_guy wrote: post #33
btgeekboy wrote: post #15

Earlier quoted context omitted.

FoundationDB is an Apple thing, isn’t it? Might explain why. It feels kinda like they’ve put it out there and it just hasn’t had anyone with a marketing budget to push it along.

It started as a proprietary database. Apple acquired it and then open sourced it eventually.

Didn't it start as an open source database? then apple acquired it and made it close sourced, then open sourced it again after several years.

It is weird that this DB has a good reputation which doesn't match its popularity.

Post reply on HN