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

191–200 of 336 posts

Re: A database for 2022

#191

Post by IshKebab »

avinassh wrote: post #180
jlokier wrote: post #97

Earlier quoted context omitted.

I don't see how CockroachDB ends up in your list of DBs that lead to vendor lock-in or being unable to run a cluster locally, because it's open source and you can run your own cluster. Is there something about it I haven't spotted that puts it in that list?

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

Re: A database for 2022

#192

Post by cbg0 »

BonoboIO wrote: post #164
hparadiz wrote: post #130

Earlier quoted context omitted.

+1 on good design and programming. My go to language of choice is PHP/MySQL. I've never not been able to scale a project. At one point while working at Comcast I prototyped a system for every error code from every cable set top box (150 million) in the country on a MySQL server instance running on a MacBook Pro pulling data from Splunk in real time. All so I could generate some png charts and embed them in Slack. I k…

But my Kubernetes Cluster on AWS can handles this for only 30.000$ a month That Comcast prototype sounds amazing. PHP and MySQL can really bring you very far, i use it for nearly everything and it is so incredible easy to develop and “deploy” new versions. I use propel as ORM and it is very close to the DB and I can change schemes fast and just let the autoupdate handle the rest.

> But my Kubernetes Cluster on AWS can handles this for only 30.000$ a month

A k8s cluster for something like that wouldn't cost anywhere that amount, plus you would get the advantage of being able to deploy your app in multiple availability zones. If you don't need k8s features, there are definitely simpler options that will give you redundancy and won't break the bank.

Re: A database for 2022

#193

Post by coderdd »

I was pondering about using simple decentralized databases that are kept synchronized asynchronously.

I arrived to a design where SQLite databases would be synchronized by Kafka. Kafka is really robust, and has a friendly semantics when configured to be in-order delivery.

The catch is, you don't issue writes to SQLite anymore. You write Kafka messages, and have to prepare to resolve concurrency problems at read+write-to-db time. For example, user registration is not an atomic action anymore - you write a registration attempt message, and then it might race with a concurrent registration attempt from an other node (say due to retries and random load balancing).

You resolve the race in message-reception time (doable due to stable order on multiple reader nodes). I expect this would work nice, but needs you to rethink all actions that used to be synchronous db writes.

Re: A database for 2022

#194

Post by hparadiz »

cbg0 wrote: post #192
BonoboIO wrote: post #164

Earlier quoted context omitted.

But my Kubernetes Cluster on AWS can handles this for only 30.000$ a month That Comcast prototype sounds amazing. PHP and MySQL can really bring you very far, i use it for nearly everything and it is so incredible easy to develop and “deploy” new versions. I use propel as ORM and it is very close to the DB and I can change schemes fast and just let the autoupdate handle the rest.

> But my Kubernetes Cluster on AWS can handles this for only 30.000$ a month A k8s cluster for something like that wouldn't cost anywhere that amount, plus you would get the advantage of being able to deploy your app in multiple availability zones. If you don't need k8s features, there are definitely simpler options that will give you redundancy and won't break the bank.

I only used a MacBook cause it was faster to ask IT for one than to have my ticket processed and approved by the cloud and security team which both required a write up on why I need a vm and what justification I have for needing it. Meanwhile IT is like "here you go".

Re: A database for 2022

#195

Post by epolanski »

jeffffff wrote: post #124
ignoramous wrote: post #95

Earlier quoted context omitted.

I'm not sure why you're being downvoted. You're right: running databases isn't for every team! Reach out for a managed database if you can. But tailscale isn't some random group of engs. They've probably got the chops to pull off literally anything they want to. I mean TFA casually mentions online cross-database transfers, multiple zero-downtime schema migrations, inspecting litestream's replication code for feasibil…

if they're this talented, is their time really best spent on dba work rather than improving the product?

Some examples: they could get rid of that pointless bootstrap on their website, they are shoving almost 1.5 MBs for a single font alone on their main page and their HTML semantics are nowhere to be found. This will all impact their bounce rate, accessibility and SEO.

I just don't believe the tale of "such skilled engineering teams" which don't show that in their products but blogposts.

Re: A database for 2022

#196

Post by lifty »

coderdd wrote: post #193

I was pondering about using simple decentralized databases that are kept synchronized asynchronously. I arrived to a design where SQLite databases would be synchronized by Kafka. Kafka is really robust, and has a friendly semantics when configured to be in-order delivery. The catch is, you don't issue writes to SQLite anymore. You write Kafka messages, and have to prepare to resolve concurrency problems at read+write…

There are more robust solutions out there for this architectural pattern. Look into dolt(dolthub) and noms.

Re: A database for 2022

#197

Post by jmconfuzeus »

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

Edit: Looks like I hurt someone's feelings in this comment.

Re: A database for 2022

#198

Post by ignoramous »

techdragon wrote: post #187
0des wrote: post #152

Earlier quoted context omitted.

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.

to quote u/InGoodFaith (news.ycombinator.com/item?id=29555814):

> Wouldn't also be HN without the misinterpretation of BrandonM's response. Here is dang's comment about that topic/meme: https://news.ycombinator.com/item?id=29178442

Re: A database for 2022

#200

Post by morelisp »

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?

The Bob Martin Sudoku Solver is the same thing but twice as expensive and replaced what little self-awareness it had with unnecessary sexual innuendo.
Post reply on HN