Live data from Hacker News

A database for 2022

tailscale.com

221–230 of 336 posts

Re: A database for 2022

#221

Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…

You say 'sometimes', I think it should be the default position. When you want to deviate from the boring software and technology, there must be a very sound 'business case' for it. If you are building a planetary scale business, OK, maybe that warrants something more fancy. But how many companies really need that? I'm not limiting myself to the HN unicorns, but looking at the whole market.

I agree with you and I also wrote:

> If you do this for the money, investing in tried and true (but boring) software should be the default solution.

Meaning if you are just playing around, then by all means evaluate new and shiny stuff.

Re: A database for 2022

#222

... this is just replication of a database? As in the full database per node/replica? Hasn't AWS's SQL db-as-a-services had this for years now?

Tailscale mention they want to run tests locally, not deal with MySQL/Postgres ops overhead themselves, and also avoid vendor lock-in (rules out RDS / Aurora, PlanetScale, CockroachDB, YugaByte, Spanner et al). May be Oracle remains an option. ;)

Maybe I'm doing something wrong, but our team has like a few dozens of PostgreSQL RDS running on AWS for the past four years and the ops is... Basically zero?

Re: A database for 2022

#223

That was a fun read but I'm missing something here. I've never worked on large scale systems and I don't understand why they didn't choose My or Postgre SQL. Some comments say that it's because they're complicated but what exactly is complicated about them? Can someone with more experience explain to me what would have happened if, for example, they used PostgreSQL from the beginning? P.S Apologies if this is a stupi…

No post body was provided.

Re: A database for 2022

#224
post #69

Earlier quoted context omitted.

sqlite is, like, the regular-est of the databases.

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.

Re: A database for 2022

#225
post #186

Earlier quoted context omitted.

What does that mean? Can you explain?

This comment trivializing Dropbox: https://news.ycombinator.com/item?id=9224

That comment is unfairly judged, taking into account how much they used AWS instead of their own solution.

"...Half-a-billion people stored files on Dropbox. Well, sort of. Really, the files were in Amazon’s cloud. .." [1]

[1] "The Epic Story of Dropbox's Exodus From the Amazon Cloud Empire"

https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama...

Re: A database for 2022

#226

Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…

> 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.

There was many new node projects using MongoDB and I remember several failed, but details elude me.

There was a Slack competitor using MongoDB that was snappy and js hipster trendy that ultimately failed because of unreliable database IIRC.

Re: A database for 2022

#227
post #63

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.

Threads on HN are very sensitive to initial conditions. A very negative (and I think pretty facile) comment took an early lead here, most likely because of its snark/dunk value. Give the thread time, it'll even out.

No post body was provided.

Re: A database for 2022

#228

I think I'm missing some context. Using a text file and using etcd as a DB for a production system seems like a terrible engineering decision. It seems like something you'd do as a proof of concept or side project. It's interesting that they're blogging about this, as if they're proud of it. I guess I'm just missing the point. This is their 3rd DB Migration, something that I prefer to avoid at all costs. I guess they…

No post body was provided.

Re: A database for 2022

#229

Earlier quoted context omitted.

First: I am not "my dude" to you. And, completely apart from the database, it's a really valid point - not a joke at all. When someone says, "It's 2022. Why are we still arguing about X?" or some such, it means that they haven't been able to persuade the rest of the world about X on the merits of their argument, and so they want to short-circuit the argument by appearing "modern" or "up to date" or "on the right side…

Quoted post unavailable.

not everything is a joke. and some jokes are not funny.

specially ad hominem criticism.

Post reply on HN