Debian contiene décadas de software acumulado: compiladores, bibliotecas, herramientas de sistema, servidores, juegos, utilidades diminutas, aplicaciones olvidadas y proyectos que continúan evolucionando después de años. Debian Code Search permite recorrer aproximadamente 130 GB de ese código fuente mediante búsquedas literales y expresiones regulares.
La imagen que uno podría construir detrás de un servicio así es fácil de anticipar: varios servidores, cantidades generosas de memoria, sistemas distribuidos, algún clúster dedicado a indexación. Sin embargo, Michael Stapelberg, creador y principal desarrollador de Debian Code Search, explicó en septiembre de 2026 que el servicio funciona actualmente sobre un único Hetzner AX52 equipado con un AMD Ryzen 7 7700 de ocho núcleos, 64 GB de RAM y dos SSD Samsung PM9A1 de 1 TB.
No es una máquina modesta en términos domésticos, pero tampoco se parece demasiado a la infraestructura que solemos imaginar detrás de un buscador capaz de consultar interactivamente una distribución completa de software libre.
La tentación inmediata es convertir las especificaciones en la historia: cuánto puede hacer hoy un procesador de escritorio acompañado de SSD rápidos. Pero eso sería quedarse con la parte menos interesante.
La pregunta no es cómo caben 130 GB en un ordenador. Eso dejó de ser sorprendente hace bastante tiempo.
La pregunta es qué tuvimos que aprender de software para que esa máquina fuese suficiente.
Buscar mejor puede significar buscar menos
Debian Code Search no recorre 130 GB de archivos desde el principio cada vez que alguien escribe una consulta. Si lo hiciera, buena parte de la potencia del servidor se desperdiciaría leyendo código que casi con seguridad no contiene lo que buscamos.
El servicio utiliza índices que permiten reducir drásticamente ese trabajo. Simplificando, en lugar de preguntarle a cada archivo si contiene una determinada secuencia, el sistema mantiene estructuras que permiten identificar primero dónde tiene sentido buscar y verificar después las coincidencias.
Esa diferencia parece una decisión técnica pequeña hasta que observamos cómo evolucionó.
Durante sus primeros años, Debian Code Search utilizaba un índice relativamente compacto que podía mantenerse en memoria. En 2019, Stapelberg experimentó con una estrategia aparentemente contraintuitiva: reemplazarlo por un índice posicional mucho más grande almacenado en disco.
La RAM es más rápida que un SSD, por supuesto. Pero el nuevo índice sabía más.
No solo podía indicar qué documentos contenían una secuencia determinada, sino también en qué posiciones aparecía. Esa información adicional permitía consultar menos listas, eliminar falsos positivos antes, abrir menos archivos y reducir una parte importante del trabajo posterior de comparación.
En las mediciones publicadas por Stapelberg entonces, el antiguo índice no posicional ocupaba unos 6,5 GB. Una variante compactada del índice posicional rondaba los 93 GB. Desde el punto de vista del almacenamiento, era una solución mucho más pesada. Sin embargo, para las búsquedas literales —que representaban alrededor del 78,2 % de las consultas estudiadas— podía terminar siendo más rápida.
La contradicción desaparece cuando dejamos de pensar únicamente en la velocidad de cada componente y observamos el sistema completo.
Más almacenamiento permitía evitar lecturas inútiles. Evitar lecturas reducía el trabajo de matching. Y reducir trabajo podía compensar con creces el hecho de consultar un índice mayor desde SSD.
Es una de esas decisiones de ingeniería que revelan una idea más amplia: optimizar no siempre consiste en realizar la misma operación más rápidamente. A veces consiste en conseguir que esa operación deje de ser necesaria.
La compresión añadió otra capa. Stapelberg adoptó TurboPFor para almacenar determinadas estructuras del índice con menos espacio y ancho de banda. En una de sus mediciones, una sección se redujo de 8,9 a 5,5 GB, acompañada incluso de una pequeña mejora de rendimiento. El intercambio era otro: menos recursos físicos a cambio de mayor complejidad en el software.
Stapelberg reimplementó la codificación y decodificación de TurboPFor aprovechando SIMD en Go y AVX-512, eliminando además la última dependencia de C del proyecto. Pero quizá el hallazgo más interesante de aquel trabajo no sea cuánto consiguió acelerar el decoder, sino lo que ocurrió después.
Llegó un momento en que hacerlo todavía más rápido dejó de mejorar perceptiblemente la búsqueda completa.
El cuello de botella se había movido.
La optimización había cumplido su función.
Existe cierta belleza en esa forma de ingeniería porque contradice tanto la fuerza bruta como el perfeccionismo. Un sistema eficiente no necesita que cada componente sea infinitamente rápido. Necesita saber dónde merece la pena gastar esfuerzo y cuándo ese esfuerzo deja de importar.
Antes de una máquina hubo seis
La infraestructura actual resulta todavía más interesante cuando se compara con la historia del mismo proyecto.
En 2014, Debian Code Search utilizaba una arquitectura distribuida. Stapelberg describió entonces cómo el índice de trigramas y el código fuente se repartían entre seis servidores físicos, cada uno con almacenamiento SSD local. La razón principal era conseguir más IOPS y menor latencia.
En aquella generación todavía podían existir consultas excepcionalmente costosas que continuaran ejecutándose durante minutos. El servicio había eliminado un timeout de 60 segundos y comenzaba a mostrar resultados parciales mientras determinadas búsquedas seguían trabajando.
Doce años después, el repositorio continúa describiendo seis shards lógicos, pero Stapelberg afirma que el servicio se encuentra detrás de un único AX52.
No tenemos una comparación perfecta entre ambos momentos. El corpus puede haber cambiado, el tráfico también, y no conocemos métricas equivalentes de disponibilidad o carga máxima para 2014 y 2026. Tampoco tendría sentido atribuir toda la consolidación al software. Los procesadores mejoraron mucho durante ese tiempo y los SSD modernos poco tienen que ver con los disponibles cuando se diseñó aquella arquitectura.
Precisamente por eso el caso resulta más interesante que una simple celebración de la optimización.
Debian Code Search fue adaptándose al hardware a medida que este evolucionaba. Cuando distribuir el almacenamiento era una manera eficaz de conseguir suficientes IOPS, se distribuyó. Cuando los SSD permitieron utilizar índices mucho mayores desde disco, el diseño cambió. Cuando la CPU moderna permitió acelerar la decodificación mediante instrucciones vectoriales, el software comenzó a aprovecharlas.
La historia no enfrenta software contra hardware. Muestra cómo ambos pueden evolucionar juntos.
Hace doce años, seis máquinas ayudaban a resolver el problema. Hoy una sola parece suficiente para alojar los seis shards. Entre ambos momentos hay procesadores y SSD mejores, pero también una década de decisiones sobre qué información conviene almacenar, qué puede comprimirse, qué debe precalcularse y, sobre todo, qué trabajo puede evitarse por completo.
Entonces, ¿por qué no hacemos esto siempre?
Porque optimizar también cuesta.
Un servidor adicional puede contratarse en minutos. Diseñar un índice posicional, cambiar patrones de I/O, comprimir estructuras, escribir implementaciones SIMD y medir cuidadosamente cada cuello de botella puede consumir semanas de una persona altamente especializada.
Durante buena parte de la historia reciente de la informática, el precio relativo de esas dos alternativas ha favorecido una conclusión perfectamente racional: muchas veces resulta más barato comprar computación que comprar tiempo de ingeniería.
Esta tensión aparece de forma casi explícita en otro buscador independiente, Marginalia Search.
Su creador, Viktor Löfgren, ha explicado que una parte de la sabiduría convencional de la industria nace en organizaciones donde el hardware es barato y el trabajo de desarrollo es caro. En un proyecto pequeño, financiado con recursos más limitados, esa ecuación puede invertirse. Si comprar otro servidor importante afecta directamente el presupuesto, dedicar más tiempo a aprovechar el hardware disponible comienza a tener sentido.
Marginalia lleva esa filosofía bastante lejos. Su servidor es muchísimo mayor que el de Debian Code Search —dos AMD Epyc 7543, 512 GB de RAM y decenas de terabytes en SSD—, pero continúa concentrando un buscador que rastrea una parte de la web en una sola máquina física.
La lección no es que los servidores únicos sean superiores.
Es que las arquitecturas también son respuestas económicas.
Lo que parece una práctica sensata para una empresa con cientos de ingenieros puede resultar absurda para una persona que mantiene un servicio prácticamente sola. Y una optimización que nunca recuperaría su coste salarial en una gran compañía puede resultar completamente razonable cuando el recurso más caro es precisamente el hardware.
Preguntar cuándo “dejamos de optimizar” conduce entonces a una respuesta menos nostálgica de lo esperado.
No dejamos de hacerlo en una fecha determinada.
Cambió el precio de las alternativas.
Una máquina puede bastar y seguir siendo insuficiente
El problema aparece cuando confundimos eficiencia con minimalismo.
En 2016, Nick Craver publicó una descripción detallada de la infraestructura de Stack Overflow. Las cifras de aquel momento ya eran considerables: cientos de millones de solicitudes HTTP diarias, cientos de millones de consultas SQL y miles de millones de accesos a Redis.
Después de años de optimizaciones y mejoras de hardware, Craver señalaba algo extraordinario: una sola máquina web podía soportar técnicamente la carga del sitio de preguntas y respuestas. Lo habían comprobado accidentalmente en algunas ocasiones.
Stack Overflow no utilizaba una sola máquina.
Mantenía nueve servidores web primarios, además de muchas otras piezas de infraestructura.
No porque necesitara nueve veces la capacidad de procesamiento, sino porque necesitaba algo distinto: redundancia, despliegues progresivos, margen ante fallos, separación entre racks y tolerancia a problemas de hardware.
La distinción es fundamental.
El mínimo computacional y el mínimo operacional no son lo mismo.
Una máquina puede tener potencia suficiente para responder todas las solicitudes y continuar siendo una pésima arquitectura de producción. Si ese servidor falla, el hecho de que fuese extraordinariamente eficiente deja de ser un consuelo.
Eso permite separar al menos tres cosas que solemos llamar simplemente “escala”.
La primera es capacidad: una máquina ya no puede completar el trabajo requerido. En ese caso, reducir lecturas, mejorar un algoritmo o utilizar mejor la memoria puede evitar comprar más hardware.
La segunda es disponibilidad: una sola máquina podría ejecutar el servicio, pero no queremos que una falla lo haga desaparecer. El segundo servidor no está corrigiendo software ineficiente. Está comprando tolerancia al fallo.
La tercera es distribución: un servicio puede necesitar presencia geográfica, menor latencia, protección contra ataques, aislamiento entre clientes o recuperación frente a la pérdida de un datacenter aunque un único computador tenga potencia suficiente para realizar todos los cálculos.
Nada de Debian Code Search permite concluir que Google Search, Amazon o cualquier plataforma mundial podrían vivir detrás de un Ryzen de ocho núcleos.
Ese nunca fue el punto.
La pregunta más útil es otra: cuando añadimos la próxima máquina, ¿qué estamos comprando exactamente?
¿Capacidad?
¿Disponibilidad?
¿Distribución?
¿O simplemente una manera más barata de no tocar un sistema cuyo trabajo podría reducirse?
Escalar hasta que deja de tener sentido
Plausible Analytics ofrece una respuesta particularmente limpia porque recorrió ambas estrategias.
La empresa describió una infraestructura que durante una etapa procesaba más de mil millones de eventos mensuales procedentes de más de 30.000 sitios web utilizando principalmente escalamiento vertical: máquinas más grandes en lugar de una arquitectura distribuida cada vez más compleja.
Luego empezó a alcanzar sus límites.
Las necesidades comenzaron a incluir recuperación frente a fallos de nodos, failover entre centros de datos, monitorización más sofisticada y escalamiento horizontal.
No hubo una conversión ideológica desde “servidores grandes” hacia “sistemas distribuidos”. Hubo un momento en que el problema cambió.
Escalar verticalmente había sido sensato mientras mantenía el sistema simple. Distribuir comenzó a serlo cuando la fiabilidad y el crecimiento hicieron que esa simplicidad dejara de compensar.
Este puede ser el contrapunto más importante de todos: la eficiencia no consiste en utilizar siempre menos máquinas. Consiste en saber por qué existe cada una.
La eficiencia tampoco es automáticamente ecología
Resulta tentador convertir Debian Code Search en una historia de computación sostenible. Una máquina necesariamente consume menos que seis, podríamos pensar.
No tenemos datos suficientes para afirmarlo con ese nivel de seguridad.
No existen públicamente, al menos en las fuentes revisadas, mediciones completas del consumo eléctrico del servidor de producción, su utilización media, la intensidad de carbono de la electricidad que lo alimenta, la huella de fabricación del hardware o su ciclo de renovación.
Podemos afirmar que Debian Code Search utiliza pocos recursos físicos para la utilidad que proporciona. Eso es frugalidad computacional.
No podemos afirmar, sin más datos, cuál es exactamente su huella ambiental.
La distinción importa porque la informática sostenible no depende exclusivamente del número de servidores. También importan cuánto tiempo permanecen encendidos sin realizar trabajo útil, cuándo son reemplazados, qué energía utilizan y qué coste material tuvo fabricarlos.
El concepto académico de frugal computing intenta precisamente reincorporar esas restricciones al diseño: tratar energía, hardware y materiales como recursos finitos que deben aprovecharse deliberadamente.
El contexto hace que la discusión sea difícil de ignorar. La Agencia Internacional de la Energía estimó que los centros de datos consumieron alrededor de 485 TWh de electricidad en 2025 y proyecta cerca de 950 TWh para 2030.
La paradoja es que la eficiencia también está mejorando.
Cada operación puede requerir menos energía mientras el consumo total aumenta porque decidimos realizar muchísimas más operaciones. Es la vieja intuición del efecto rebote trasladada a la infraestructura digital: hacer algo más barato puede provocar que terminemos haciéndolo más.
Debian Code Search muestra una trayectoria diferente. Sus mejoras parecen haber permitido consolidar infraestructura en lugar de convertir cada ganancia en una excusa para expandirla.
No sabemos si ese fue deliberadamente el objetivo ambiental del proyecto.
Pero sabemos que técnicamente ocurrió algo interesante: una parte creciente del rendimiento fue obtenida no añadiendo capacidad, sino entendiendo mejor qué trabajo podía eliminarse.
La eficiencia también es conocimiento
Hay algo profundamente artesanal en sistemas como Debian Code Search.
No porque sean pequeños ni porque hayan sido construidos fuera de una gran corporación, sino porque conservan una relación visible entre conocimiento técnico y recursos materiales.
El servidor actual no es suficiente solamente porque AMD fabrica procesadores rápidos o Samsung buenos SSD.
Es suficiente porque durante más de una década alguien decidió qué representación debía tener el índice, qué información convenía conservar, qué podía comprimirse, cuándo usar RAM, cuándo confiar en NVMe, qué falsos positivos podían eliminarse antes, qué parte del decoder justificaba SIMD y cuándo continuar optimizandolo dejaba de cambiar el resultado.
Esa acumulación de decisiones también es infraestructura.
En el artículo sobre Wine observábamos que el software libre puede funcionar como conocimiento acumulado: años de compatibilidad, pruebas y soluciones permanecen disponibles para que otros construyan encima.
Debian Code Search permite mirar otra cara de esa misma idea.
La eficiencia también puede acumularse como conocimiento.
No aparece solamente en un benchmark final. Se deposita en estructuras de datos, formatos, algoritmos, decisiones incómodas, pruebas descartadas y comprensión de los límites del hardware.
Por eso la pequeña ficha técnica del AX52 termina siendo menos importante después de conocer la historia.
Ryzen 7 7700.
64 GB de RAM.
Dos SSD.
Una máquina.
Al principio parecen especificaciones.
Después comienzan a parecer otra cosa: el resultado físico de una década aprendiendo cuánto trabajo no hacía falta hacer.
Y quizá esa sea una pregunta que valga la pena recuperar en una época en que aumentar recursos se ha vuelto extraordinariamente fácil.
Frente al próximo servidor que añadamos, tal vez no deberíamos preguntarnos solamente cuánto más podremos hacer con él.
Antes convendría preguntarnos cuánto de lo que ya estamos haciendo necesitaba hacerse.
