Bluesky migra a SQLite de inquilino único

• Bluesky migró a un datastore SQLite de inquilino único.
• Ahora cada usuario tiene su propio archivo SQLite para almacenar su repositorio y el estado privado de su cuenta.
• Las bases de datos de usuarios se almacenan de forma jerárquica.
• La clave de firma del repositorio de cada repositorio se guarda junto con el archivo SQLite.
• La abstracción que interactúa con los datos de usuario pasó a ActorStore.
• ActorStore tiene clases distintas para lectura y escritura.
• Como SQLite no soporta transacciones concurrentes, ActorStore requiere un "transact" explícito para escribir.
• Se mantiene un LRUCache para las claves de firma y las bases de datos, permitiendo 30k file handles abiertos y 30k claves mantenidas en memoria.
• Cuando una base de datos sale del caché, se cierra el file handle.
• Se introdujeron tres bases de datos SQLite separadas para gestionar el estado del servicio: una service DB para información de cuentas, códigos de invitación, refresh tokens, etc.; una did cache DB para cachear la resolución de DID; y una sequencer DB para procesar secuencialmente las actualizaciones de repositorios de todos los repositorios del servicio.
• Estos archivos SQLite se ejecutan en modo WAL para permitir lecturas concurrentes y replicación por streaming.
• Se espera que el despliegue de PDS se distribuya junto con Litestream o algo similar.

[GN⁺]

Comentarios en Hacker News

• Bluesky migró a una configuración de SQLite de un solo inquilino, lo que generó debate sobre los desafíos y beneficios de este enfoque.
• Algunos usuarios expresan preocupación por posibles problemas con la migración de datos, las versiones del esquema y la futura necesidad de agregación de datos.
• Otros ponen en duda la afirmación de que SQLite no soporta transacciones concurrentes, y señalan que sí las admite bajo ciertas condiciones.
• La estrategia de una proporción 1:1 entre usuario y base de datos parece interesante, y surgieron preguntas sobre cómo se manejarán los datos que deban agregarse entre usuarios.
• También hay interés en cómo esta configuración gestionará las actualizaciones a la base de datos de un usuario cuando otros usuarios publiquen contenido nuevo.
• Algunos usuarios elogian la adopción de SQLite/Litestream en el servidor, citándolo como una opción rentable para bases de datos de inquilinos.
• Surgieron preguntas sobre qué tipos de datos se almacenan en SQLite y cuáles no; algunos usuarios suponen que los mensajes entre usuarios no se guardan en SQLite.
• Se sugiere que usar un hash MD5 para obtener directorios de destino de dos caracteres sería más rápido y resolvería el mismo problema en lugar de un hash SHA256.
• Algunos usuarios ven esta migración como un movimiento positivo y sugieren que sería fácil dejar el servicio descargando un archivo SQLite y creando un frontend HTML solo local.
• Hay una pregunta sobre si Bluesky sigue siendo solo por invitación.