Cobrar las bases de datos por lo que realmente usan

Cada app de Mythex que necesita guardar datos tiene su propia base de datos Postgres, y el uso de la base de datos de una app publicada sale del mismo saldo de créditos que la construcción. Hasta finales de septiembre estimábamos ese uso según cuánto tiempo estaba en marcha el servidor de la app. La estimación resultó errónea de una forma que importaba, así que la sustituimos: ahora cada base de datos se factura según el cómputo que su proveedor midió realmente, una hora terminada cada vez, y cada hora solo puede cobrarse una vez.

Cómo funcionan las bases de datos

Cada base de datos se ejecuta en Postgres sin servidor que escala a cero: tras unos minutos inactiva, se duerme, y se despierta con la siguiente consulta. Mientras está despierta, puede subir y bajar su cómputo según la carga. Eso es lo que hace asequible “una base de datos por app”: la mayoría de las apps están tranquilas la mayor parte del tiempo, y una base de datos dormida casi no cuesta nada.

Eso también significa que el coste de una base de datos depende de dos cosas que no vemos desde fuera: cuánto tiempo estuvo despierta y qué tamaño tenía mientras estaba despierta.

En qué se equivocaba la estimación

Nuestro medidor original hacía una suposición: por cada hora que el servidor de una app publicada estaba en marcha, cobrar una base de datos al tamaño de cómputo más pequeño.

Eso estaba mal de tres maneras:

El tamaño era incorrecto. Las bases de datos funcionaban en un tamaño por defecto mayor del que suponía la estimación.
Las bases de datos escalan automáticamente. Bajo carga crecen, y la estimación nunca lo veía.
Las bases de datos no siguen al servidor de la app. Una base de datos se mantiene despierta siempre que algo la consulta —la app, un trabajo programado, un script que la sondea—, tanto si el servidor de la app estaba activo como si no.

El efecto neto: la estimación cobraba a los usuarios aproximadamente la mitad de lo que realmente costaban las bases de datos. Eso no es sostenible para nosotros, y además hacía que los números de uso de la app no significaran lo que la gente creía que significaban.

Medir en lugar de adivinar

Nuestro proveedor de bases de datos informa del segundo-unidad de cómputo por hora de cada proyecto: cuánto cómputo usó realmente, incluido el tamaño. Así que el medidor ahora funciona de esta manera:

Para cada app publicada con base de datos, obtener el uso medido de cada hora terminada desde que la app salió en vivo.
Convertir ese uso en coste al precio del proveedor, aplicar la tarifa del plan y cargarlo a los créditos del propietario de la app.
Mirar hacia atrás hasta un día en cada ejecución, para que las horas perdidas mientras nuestra API se reiniciaba se cobren más tarde.

El almacenamiento se factura aparte, por tamaño, porque no depende de la actividad.

Nunca cobrar una hora dos veces

Un medidor de facturación que se ejecuta en más de un servidor —y que puede fallar y reintentarse— tiene que tener cuidado de no cobrar doble. Cada hora de cada base de datos se reclama en su propia fila de la base de datos antes de cobrarse, con una restricción de unicidad sobre el par (base de datos, hora). Si dos servidores, o un reintento, intentan facturar la misma hora, solo una reclamación tiene éxito.

También tomamos una decisión deliberada para el caso de fallo poco frecuente: si el proceso se cae entre reclamar una hora y cobrarla, esa hora queda reclamada y sin facturar. Perder una pequeña parte de los ingresos en una caída rara es mejor que cobrar a alguien dos veces.

Y cuando se activó la facturación medida, empezó desde la siguiente hora completa. Las horas anteriores ya se habían cobrado con la estimación antigua; facturarlas de nuevo a partir de datos medidos habría cobrado dos veces ese tramo.

Qué significa esto si construyes en Mythex

Tu factura de base de datos ahora refleja lo que hizo tu base de datos. Una app que se usa poco cuesta muy poco; una app que consulta su base de datos constantemente la mantendrá despierta y costará más.
La palanca más grande es cómo usa tu app la base de datos. Sondear la base de datos cada pocos segundos la mantiene despierta todo el día. Pedir a la IA que obtenga los datos bajo demanda, o guardarlos en caché, permite que la base de datos duerma. Nuestra guía sobre qué es una base de datos cubre lo básico.
Los planes Pro pagan la mitad de la tarifa Free por alojamiento, bases de datos y almacenamiento. Los detalles están en la documentación de créditos.

Lo que aprendimos

Las estimaciones de costes basados en el uso se desvían. Cuando el proveedor de origen puede decirte qué se usó, factura a partir de eso.
Haz que la facturación sea idempotente en la unidad más pequeña que cobras. Para nosotros, es una hora de base de datos.
Cuando tienes que fallar, falla a favor del cliente.