Live data from Hacker News

Bluesky migrates to single-tenant SQLite

github.com

61–70 of 247 posts

Re: Bluesky migrates to single-tenant SQLite

#61

Earlier quoted context omitted.

don't know why, but recent teams around me have always made strict rules about number of commits in PRs. I just wanted to tell them the same thing you said: "Why don't you just look at the diffs?" curious for other opinions. (sorry not really about this particular topic)

I prefer to have clear commits that tell a tidy story. For example: * Refactor function `foo` to accept a second parameter * Add function `bar` * Use `bar` and `foo` in component `Baz` to implement feature #X If you give me a commit history like this, I can easily validate that each step in your claimed process does what you describe. If you instead give me a messy history and ask me to read the diff, you might know…

Funny that two of your commits don't actually tell us why they exist, one simply describes the diff (which you should never need lol?) and the other proxies that responsibility to some other system.

You could have simply randomized the text in each commit, put the ticket id and the one "why" in the merge commit body and gotten the same end result amount of real information in the end.

Re: Bluesky migrates to single-tenant SQLite

#64

Love SQLite - in general there are many challenges with a schema or database per tenant setup of any kind though. Consider the luxury of row-level security in a shared instance where your migration either works or rolls back. Not now! If you are doing a data migration and failed to account for some unexpected data, now you have people on different schema versions until you figure it out. Now, yes, if you are at shard…

https://blog.turso.tech/introducing-embedded-replicas-deploy...

https://electric-sql.com/

Re: Bluesky migrates to single-tenant SQLite

#65
post #63

Why sha256 hash the user into to get a two character target directory? Wouldn't md5 be much faster and solve the same problem?

At their scale maybe they're worried about collisions?

Or, like me, they're drowning in security tooling from corporate and don't want to have to carve out exceptions for md5 usage in each.

Re: Bluesky migrates to single-tenant SQLite

#66
post #63

Why sha256 hash the user into to get a two character target directory? Wouldn't md5 be much faster and solve the same problem?

It's probably not healthy to have broken cryptographic hashes running around. If you don't need a secure hash there are plenty of fast non-cryptographic hashes.

Re: Bluesky migrates to single-tenant SQLite

#67

Love SQLite - in general there are many challenges with a schema or database per tenant setup of any kind though. Consider the luxury of row-level security in a shared instance where your migration either works or rolls back. Not now! If you are doing a data migration and failed to account for some unexpected data, now you have people on different schema versions until you figure it out. Now, yes, if you are at shard…

I dont know - I have experience working with monster DBs in production and never again. Under large enough load every change becomes risky because you can’t test performance corner cases fully. Having a free-tier user take out your prod because they found a non-indexed code path is also classic

Re: Bluesky migrates to single-tenant SQLite

#68
post #40

Earlier quoted context omitted.

Is your offer invite code available to other randoms like myself? I tried to register on bsky months ago and still haven't been approved.

I have some extra if you'd like one. Let me know how to get it to you and I will.

Would also like one if you have an extra. Thx in advance. (Click on username to see my email in profile)
Post reply on HN