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

251–260 of 336 posts

Re: A database for 2022

#251

Post by carapace »

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…

(Not to namedrop, but, uh) I know apenwarr glancingly IRL and he's amazing. A force of nature. When people talk about "10x" programmers I think of him.

Re: A database for 2022

#252

Post by jen20 »

epolanski wrote: post #90
bradfitz wrote: post #28

Earlier quoted context omitted.

Tailscale employee here. Our database needs are tiny, as explained in the earlier post. So we optimize for things like: "can we run all our tests quickly and easily in many environments without containers and VMs?" All three of our storage schemes have had that property. We have MySQL and PostgreSQL veterans on the team. We know those options well.

> we run all our tests quickly and easily in many environments without containers and VM How's that an important metric to optimize for? Did you ever benchmark the tests with other solutions?

In what world would “make dev environments better” _not_ be an important thing?

Re: A database for 2022

#253

Post by database_guy »

vinay_ys wrote: post #235
rsp1984 wrote: post #220

Earlier quoted context omitted.

> I watched with dread how the MongoDB fiasco played out a decade ago. Could you elaborate on this? MongoDB as a company is worth $30B, so it looks like they did at least some things right.

Their paid managed service works well for enterprise SaaS companies who need It also works well for early stage Consumer Internet startups that haven't yet achieved huge growth but care a lot about developer productivity while churning features at high velocity. But it gets blamed for reliability issues suffered by highly successful Consumer Internet companies that have achieved scale and have DAU, MAU in > 10M and h…

At work I have a multi-petabyte cluster in MongoDB Atlas with no issues. The managed service is fantastic; I'm going to need some citations on how it degrades after a few terabytes. I don't really like MongoDB's document-model-everywhere approach but I have to respect how well their managed service works.

Re: A database for 2022

#254

Post by tptacek »

mekster wrote: post #224
isbvhodnvemrwvn wrote: post #203

Earlier quoted context omitted.

Not quite, I got bitten by weak type system more than once.

Funny in here, people praise SQLite but dismiss MySQL when it's tiny bit off the SQL standard and people complain how PHP converts values with best effort guess on different types but not when SQLite does that too. Don't know why anyone would use SQLite in production except for as some KV store embedded in an app.

Because an SQL engine that defers control over connections, concurrency, storage, and process management to users is extremely valuable for multiple reasons, including simple cases like caches where you'd ordinarily just store things in flat files or BerkleyDB-style database, and complex cases like distributed statekeeping where existing SQL databases aren't going to do anything close to the right thing for your application, but you also don't want to reinvent SQL and query planning and write-ahead-logs to build your complex database.

The vibe I get from this thread is that a lot of people have only experienced SQLite from the vantage point of something like Rails running in a "test" environment, and are used to explaining to people on some PHPbb somewhere that you can't really use SQLite to back a multiuser SAAS app. That's as may be, but when you're building infra components, you control who the "users" are; not everything is a web server taking requests from all comers.

Re: A database for 2022

#255

Post by tptacek »

throwdbaaway wrote: post #240
tptacek wrote: post #137

Earlier quoted context omitted.

One obvious reason not to use RDS is wanting disk-local caches of information replicated from a single leader, rather than having every single machine in your fleet calling out to an external service on every read . That's certainly why we're not considering Postgres in our infrastructure, even though managed Postgres is a product we in fact offer. We use Postgres! It's the backing state for our API, and an important…

Sounds like postgres listen/notify could be viable for your high-read-low-write use case? Or it is not scalable enough for the fleet size?

That's still all your infrastructure components calling out to an external service on every read --- and for what advantage?

This isn't an app server; it's an infrastructure component, running (I don't know about Tailscale here, but we use SQLite in similar uses cases) on potentially hundreds or thousands of machines.

Re: A database for 2022

#256

Post by vvern »

IshKebab wrote: post #191
avinassh wrote: post #180

Earlier quoted context omitted.

CockroachDB is licensed under BSL, so it is not really open source rather a source open or source available project. I checked their LICENSE file [0] and it mentions bunch of other open source licenses with BSL. I randomly checked a code file [1] and it seems the code is licensed under BSL. [0] - https://github.com/cockroachdb/cockroach/blob/2c4e2c6/LICENS... [1] - https://github.com/cockroachdb/cockroach/blob/2c4e2c…

Very interesting. I'd never heard of it but apparently MariaDB uses it too. TL;DR is the source is available but you can't use it in production without paying a fee. However versions older than 4 years become truly open source, so you can use old versions for free. Interesting compromise. Might be better than "open core".

That’s not quite right. You can very much use the bsl code in production without a license and many, many companies do. The BSL contains a space for additional use grants. In crdb’s license, you can use the product for anything except building a hosted database as a service product. The definition of what that is is a little bit vague but it more or less means that the users of the product you sell shouldn’t be able to cause schema changes. This is all just protection against cloud providers taking the product and reselling it. I believe also the terms of this bsl are that it becomes Apache 3 years after the code has been released.

Re: A database for 2022

#257

Post by mrkurt »

hokus_p2 wrote: post #212
jeffffff wrote: post #156

Earlier quoted context omitted.

i really don't know a ton about this product or team but it sounds like if they had used aurora mysql or aurora postgres in the first place then there would be nothing to write a blog post about because it would've just worked and kept working. they say they want to avoid vendor lock-in but if the vendor became a real issue they'd be doing their first migration instead of being on v3 already. additionally, their besp…

>> it seems like they are successful in spite of these decisions, not because of these decisions That is my conclusion, too.

The thing about startup decisions is: most of them are "wrong". Or they start right and become wrong later. Successful startups aren't successful in spite of their wrong decisions, they're successful because they can change them very quickly (then write a blog post about it and get more customers).

There's also a strong correlation between people who look at things from weird angles and also build good products. Why are you surprised the people who invented an entirely new way of doing VPNs also don't cargo cult database storages?

Re: A database for 2022

#258

Post by yawaramin »

jeffffff wrote: post #156
tptacek wrote: post #144

Earlier quoted context omitted.

"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…

i really don't know a ton about this product or team but it sounds like if they had used aurora mysql or aurora postgres in the first place then there would be nothing to write a blog post about because it would've just worked and kept working. they say they want to avoid vendor lock-in but if the vendor became a real issue they'd be doing their first migration instead of being on v3 already. additionally, their besp…

Sounds like you need to do a lot more research before commenting on this? It's pretty easy to find in the Litestream docs that it replicates to S3, Google Cloud Storage, Azure, and other options even including SFTP. In fact by off-loading the storage integration details to Litestream, the Tailscale people now get seamless storage vendor independence almost for free.

This is what a really smart and future-proof solution looks like.

Re: A database for 2022

#259

Post by jeffffff »

yawaramin wrote: post #258
jeffffff wrote: post #156

Earlier quoted context omitted.

i really don't know a ton about this product or team but it sounds like if they had used aurora mysql or aurora postgres in the first place then there would be nothing to write a blog post about because it would've just worked and kept working. they say they want to avoid vendor lock-in but if the vendor became a real issue they'd be doing their first migration instead of being on v3 already. additionally, their besp…

Sounds like you need to do a lot more research before commenting on this? It's pretty easy to find in the Litestream docs that it replicates to S3, Google Cloud Storage, Azure, and other options even including SFTP. In fact by off-loading the storage integration details to Litestream, the Tailscale people now get seamless storage vendor independence almost for free. This is what a really smart and future-proof soluti…

or they could have used mysql or postgres hosted by aws, gcp, azure, etc? i would put money on this not being the last time they change databases

Re: A database for 2022

#260

Post by jeffffff »

mrkurt wrote: post #257
hokus_p2 wrote: post #212

Earlier quoted context omitted.

>> it seems like they are successful in spite of these decisions, not because of these decisions That is my conclusion, too.

The thing about startup decisions is: most of them are "wrong". Or they start right and become wrong later. Successful startups aren't successful in spite of their wrong decisions, they're successful because they can change them very quickly (then write a blog post about it and get more customers). There's also a strong correlation between people who look at things from weird angles and also build good products. Why…

it's not cargo culting if it works, and they even say in the article that mysql or postgres would've worked

maybe next they will stop cargo culting operating systems and switch to SerenityOS?

Post reply on HN