Facturar las bases de datos según lo que realmente usan

Cada app de Mythex que necesita guardar datos obtiene 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 a partir del tiempo que el servidor de la app estaba en marcha. La estimación resultó estar mal de una forma que importaba, así que la sustituimos: cada base de datos se factura ahora a partir del cómputo que su proveedor midió realmente, una hora completa cada vez, y cada hora solo puede cobrarse una vez.

Cómo funcionan las bases de datos

Cada base de datos funciona sobre Postgres sin servidor que escala a cero: tras unos minutos de inactividad se duerme, y se despierta con la siguiente consulta. Mientras está despierta, puede subir o 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.

Esto también significa que el coste de una base de datos depende de dos cosas que no podemos ver desde fuera: cuánto tiempo estuvo despierta y cuán grande era mientras estaba despierta.

En qué se equivocaba la estimación

Nuestro medidor original hacía una suposición: por cada hora en 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 era incorrecto en tres aspectos:

1. El tamaño era incorrecto. Las bases de datos funcionaban en realidad con un tamaño predeterminado mayor del que suponía la estimación.
2. Las bases de datos escalan automáticamente. Con carga crecen, y la estimación nunca lo veía.
3. Las bases de datos no siguen al servidor de la app. Una base de datos permanece despierta siempre que algo la consulta —la app, un trabajo programado, un script que la consulta cada cierto tiempo—, tanto si el servidor de la app está activo como si no.

El efecto neto: la estimación cobraba a los usuarios aproximadamente la mitad de lo que las bases de datos costaban de verdad. 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.

Medir en lugar de adivinar

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

1. Para cada app publicada con base de datos, obtiene el uso medido de cada hora terminada desde que la app se publicó.
2. Convierte ese uso en coste al precio del proveedor, aplica la tarifa del plan y lo carga a los créditos del propietario de la app.
3. Mira hasta un día atrás en cada ejecución, de modo que las horas perdidas mientras nuestra API se reiniciaba se facturen más tarde.

El almacenamiento se factura por separado, según su 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 reintentar, 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 ingresos en un fallo raro es preferible a cobrar dos veces a alguien.

Y cuando la facturación medida se activó, 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

• La factura de tu base de datos ahora refleja lo que hizo tu base de datos. Una app poco usada cuesta muy poco; una app que consulta su base de datos constantemente la mantendrá despierta y costará más.
• La palanca más importante es cómo usa tu app la base de datos. Consultarla 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 los fundamentos.
• 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 uso se desvían. Cuando el proveedor de origen puede decirte lo que se usó, factura a partir de eso.
• Haz la facturación idempotente en la unidad más pequeña que cobras. Para nosotros, una hora de base de datos.
• Cuando tengas que fallar, falla a favor del cliente.