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

241–250 of 336 posts

Re: A database for 2022

#241

Post by diarrhea »

vaughandroid wrote: post #213
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…

Please could someone explain the "Bob Martin Sudoku Solver energy" reference?

All I found: https://news.ycombinator.com/item?id=15441323

Re: A database for 2022

#242

Post by throwdbaaway »

It has been almost 15 months since the previous blog post:

> Unfortunately, if we want to move to running more than one CONTROL process simultaneously for high-availability and better release management, that means we no longer have exactly one process managing the data

Do you guys still only have 1 CONTROL process?

Re: A database for 2022

#243

Post by jhgb »

rr808 wrote: post #230

I loved filed based h2 as well. Is there any reason in 2022 to use h2 over sqlite?

Probably not if you can just jump to a single-file Firebird database, and open that one either in embedded (single-user) or server (multi-user) mode.

Re: A database for 2022

#244

Post by structural »

bradfitz wrote: post #125
jbmsf wrote: post #101

Earlier quoted context omitted.

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…

Tailscale engineer here. Unrelated. We just haven't worked on it much. A bunch of other stuff has been a higher priority. But better ACL management will happen.

This is great to hear. We've been happy users for a couple of years, and the device tagging support has come a long way (and is a big enabler for sensible ACLs), but trying to use Tailscale's ACLs in general has been our biggest pain point with the product.

Re: A database for 2022

#245

Post by UncleEntity »

alophawen wrote: post #226
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.

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.

How many crypto currency projects went down with $million+ losses due to using mongoDB as the backend?

Re: A database for 2022

#246

Post by benbjohnson »

ignoramous wrote: post #166
jeffffff wrote: post #160

Earlier quoted context omitted.

> When TFA points out that zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, I think it is for this reason. if zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, why are they using s3? migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted…

> migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres You may be right. I have no experience migrating litestream but from the docs ( https://litestream.io/guides/ ) it is literally cp'ing files from S3 to wherever and exec'ing one of these one-liners (of course, the devil is i…

Litestream author here. Yeah, you're basically right but it's simpler than a DB migration. No need to copy the old data over. You can remove the `-litestream` metadata directory and point it at a new replication destination and it'll automatically re-snapshot the database begin replication.

Re: A database for 2022

#247

Post by benbjohnson »

didip wrote: post #145

So… litestream is bidirectional? Nothing can go wrong when daemon A and daemon B write almost at the same time? Edit: I just found this tips and gotcha page: https://litestream.io/tips/

Litestream author here. I'm glad you were able to track down what you were looking for. For posterity, I'll add a response here. Litestream is a one-way, physical replication tool so you have a single primary node that continuously copies changes out to an external destination (S3, SFTP, etc).

If you're looking to have multiple primaries then you can try using the SQLite session extension[1] and copying patch files. That's quite a bit more complicated though.

[1]: https://www.sqlite.org/sessionintro.html

Re: A database for 2022

#248

Post by jen20 »

tapirl wrote: post #110
database_guy wrote: post #33

Earlier quoted context omitted.

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.

No, it was not open source prior to Apple releasing it as Apache 2.0 in April of 2018.

Re: A database for 2022

#249

Post by dangoor »

isbvhodnvemrwvn wrote: post #203
mrkurt wrote: 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.

Enough people have had this complaint that sqlite has added STRICT tables: https://www.sqlite.org/stricttables.html

Re: A database for 2022

#250

Post by benbjohnson »

kevin_nisbet wrote: post #80
ramenmeal wrote: post #18

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…

> But I'm just confused, why would an engineer want to join a company that is making these decisions? Why would the company want their users to know about these decisions? This might actually be a really good filter for which types of engineers are good fit for their company. Because my read was very different than yours, as I looked at the decision lineage and thought to myself I could see myself making every one of…

Litestream author here. The default configuration is to replicate any new changes every second to S3. This is mainly a cost issue though. S3 doesn't charge for ingress bandwidth but it does charge $0.000005 per PUT request. If you have a non-stop, continuous stream of writes against your database then that's about $12/mo. In practice, most people don't have a continuous stream of writes. Michael Lynch, for example, wrote a post about how he pays $0.03/month for his Litestream replication[1].

I've worked with Raft a lot in my career. I wrote the original etcd Raft implementation (sorry!) [2] and even wrote a visualization explaining Raft[3]. It's a great tool when you need really high durability guarantees but I'm not convinced it gives you better availability guarantees than a single node that can quickly be recovered.

[1]: https://mtlynch.io/litestream/ [2]: https://github.com/goraft/raft [3]: http://thesecretlivesofdata.com/raft/

Post reply on HN