Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bluesky migrates to single-tenant SQLite

github.com

Post reply on HN
Print view View original

141–150 of 247 posts

Re: Bluesky migrates to single-tenant SQLite

#141

Post by BiteCode_dev »

Tomte wrote: post #99
nyx2d wrote: post #76

Earlier quoted context omitted.

They have over 1.8 million users currently, or do you mean PDSes specifically? Federation is in open beta on a test network, you can try it out today if you'd like.

I have been on the wait list since they launched. They seem to mostly rely on invites.

Got a few invites, DM me on twitter, substack or masto if you want them (listing on https://bitecode.dev)

Re: Bluesky migrates to single-tenant SQLite

#142

Post by numpad0 »

greyface- wrote: post #138
numpad0 wrote: post #133

Earlier quoted context omitted.

No one seems to be taking two codes I'm putting up without the prefix for ~hour, this is likely the case e: second one now used, first still up e: both used

I wonder what they're being used for. The UI doesn't expose it, but the Bluesky API will tell you who redeemed your invites. Open the site, watch for a "com.atproto.server.getAccountInviteCodes" request in your browser's network inspector, look in the "usedBy" field in the response JSON, and append the DID value there onto " https://bsky.app/profile/ ". Any commenters in the parent chain who got scraped want to take…

I get "$username joined using your invite code!" in notification tab that leads to the user profile. So far the user hasn't done anything.

Re: Bluesky migrates to single-tenant SQLite

#143

Post by garblegarble »

WinstonSmith84 wrote: post #140
felixthehat wrote: post #118

Earlier quoted context omitted.

bsky-social-scbch-eolha bsky-social-fs26y-d6gnv bsky-social-2lx5u-ntrdv bsky-social-hboq7-dyuue bsky-social-b2v3f-3a23q

damn, seems already all gone

    bsky-social-lkzsp-7x7ja
    bsky-social-p4vwr-nrthu
    bsky-social-bdu6c-6tbv4
    bsky-social-fkpgk-oestw

Re: Bluesky migrates to single-tenant SQLite

#147

Post by gigatexal »

lucasyvas wrote: post #19

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…

> 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 sharding scale this may occur anyway, but consider that before you hit that point, a single database is easiest.

This can be accounted for and handled. Though if schema issues are enough of a scare I wonder if a documentdb style embedable database like a couch/pouchdb might make more sense.

Re: Bluesky migrates to single-tenant SQLite

#149

Post by gigatexal »

viraptor wrote: post #119
lucasyvas wrote: post #19

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…

> 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. That shouldn't be a big issue. Any service large/complex enough to care does the schema upgrades in phases, so it's 1. Make code future compatible. 2. Migrate data. 3. Remove old schema support. So typically it should be safe to run between steps 1 and 2 for a l…

> That shouldn't be a big issue. Any service large/complex enough to care does the schema upgrades in phases, so it's 1. Make code future compatible. 2. Migrate data. 3. Remove old schema support.

Exactly this, schema migrations should be an append, deprecate, drop operation over time.

Post reply on HN