El autoalojamiento es lo predeterminado, no el plan B

La mayoría de bases de datos son un servidor con el que hablas por red. Ejecutas un proceso, abres un puerto, gestionas usuarios y tu aplicación se conecta a él como cliente. Ese modelo tenía sentido cuando una base de datos era un mainframe compartido; lo tiene menos cuando el “servidor” es un contenedor al lado de tu aplicación que no hace más que atender a un solo servicio.

Arkeion es distinto: es un motor embebido. cargo add arkeion y la base de datos vive dentro de tu aplicación como biblioteca, leyendo y escribiendo un único fichero. No hay puerto que abrir, ni un segundo proceso al que cuidar, ni salto de red entre tu código y tus datos. La base de datos está a una llamada de función de distancia.

Esa última frase es toda la historia de seguridad en miniatura. Una base de datos embebida no tiene superficie de ataque propia — no hay nada que alcanzar por la red, porque no hay red. En el momento en que decides que otras máquinas deben hablar con tus datos, eres tú quien abre esa puerta, deliberadamente, y eres tú quien decide qué la guarda.

El momento en que una base de datos da la cara a internet

Muchos sistemas reales sí necesitan una base de datos accesible desde fuera: una app móvil que sincroniza con un backend, una herramienta interna expuesta a un equipo, una API que sirve datos a socios. En cuanto un endpoint es público, deja de ser un fichero tranquilo y se convierte en un objetivo. Los ataques no son exóticos; son constantes y automatizados:

• Abuso de tasa y denegación de servicio — un solo cliente machacándote hasta tumbarte, o una botnet haciéndolo a propósito.
• Payloads maliciosos — intentos de inyección, cuerpos desmesurados, peticiones malformadas tanteando en busca de un cuelgue.
• Credential stuffing — contraseñas reutilizadas rociadas contra tu autenticación, miles por segundo.
• Scraping — recolección lenta y paciente de todo lo que estés dispuesto a entregar.

Este es el principio de diseño al que volvemos una y otra vez: ese trabajo defensivo no pertenece al interior de la base de datos. El trabajo de un motor de consultas es responder consultas correctamente y rápido, no adivinar qué llamantes son hostiles. Atornilla el rate-limiting y la inspección de payloads dentro del motor y obtendrás un motor más lento y un escudo más débil. El escudo va delante, como capa propia, donde puede descartar tráfico malo antes de que llegue a costarte una consulta.

quoxy pone quota delante

Esa capa frontal es quota: rate-limiting, un WAF, un escudo de API, analítica y una red edge — la maquinaria de un endpoint público endurecido, sin que tengas que construirla. quoxy es la pieza que une los dos mundos: conecta tu Arkeion autoalojado con quota, de modo que cada petición de fuera pasa primero por quota, y solo el tráfico limpio y permitido llega a tu base de datos por una conexión segura.

Como la dirección pública es la de quota y no la de tu base de datos, tu Arkeion nunca tiene por qué ser directamente accesible. Solo escucha a quoxy. El radio de explosión de un error se encoge en consecuencia: no hay ningún puerto de base de datos abierto en internet que encontrar, solo un edge construido para que lo encuentren.

Qué hace realmente cada capa

El valor está en el orden en que ocurren las cosas. Una petición recorre una carrera de obstáculos, y cada etapa puede poner fin a su viaje:

• Rate-limiting — presupuestos por clave y por ruta. Un llamante recibe su parte justa y no más; una avalancha se descarta en el edge, lejos de tu motor, antes de que pueda convertirse en carga.
• WAF — inspección de payloads. Las formas conocidas como maliciosas (cadenas de inyección, cuerpos malformados, subidas desmesuradas) se descartan nada más verlas.
• API shield — autenticación y validación de esquema antes de la base de datos. Una petición sin clave válida, o con un cuerpo que no cumple el contrato, nunca llega a ser una consulta. Tu motor solo ve llamadas bien formadas y autorizadas.
• Analítica — ves el tráfico: quién llama, con qué frecuencia, qué se está bloqueando y por qué. La protección que no puedes observar es protección en la que no puedes confiar.
• Edge — todo lo anterior corre cerca de tus usuarios, así que el escudo añade un salto medido en milisegundos de un solo dígito en lugar de una vuelta al planeta.

Por qué lo construimos así

Estas no son razones de marketing. Son las razones:

• Es tuya. Tu base de datos es un fichero. Puedes copiarlo, exportarlo, respaldarlo y marcharte con él cuando quieras. No hay datos rehenes — nada tuyo que solo funcione mientras nos sigas pagando.
• Puedes irte. El motor es MIT/Apache. Esa licencia es una promesa que no podemos revocar: construyamos lo que construyamos encima, lo de debajo sigue siendo tuyo y sigue siendo libre.
• La protección es lo predeterminado, no un extra de pago. Exponer una base de datos sin nada delante es un tiro en el pie, y no creemos que el camino seguro deba ser el caro. quoxy existe para que “ponerla en internet” y “protegerla” sean la misma decisión, no dos.

Autoalojamiento primero. Protegida por defecto. Tuya, siempre. Esa es toda la idea — y es la misma idea que hay debajo de todo lo demás que hacemos.