Fakturering av databaser etter det de faktisk bruker

Hver Mythex-app som trenger å lagre data, får sin egen Postgres-database, og en publisert apps databasebruk trekkes fra det samme kredittsaldoet som bygging. Fram til slutten av september estimerte vi denne bruken ut fra hvor lenge appens server hadde kjørt. Estimatet viste seg å være feil på en måte som betydde noe, så vi erstattet det. Hver database faktureres nå etter beregningen leverandøren faktisk har målt, én ferdig time om gangen, og hver time kan bare belastes én gang.

Slik fungerer databasene

Hver database kjører på serverless Postgres som skalerer ned til null: etter noen få minutter uten aktivitet sover den, og den våkner ved neste spørring. Mens den er våken, kan den skalere beregningskapasiteten opp og ned med belastningen. Det er det som gjør «en database per app» overkommelig. De fleste apper er stille mesteparten av tiden, og en sovende database koster nesten ingenting.

Det betyr også at kostnaden for en database avhenger av to ting vi ikke kan se utenfra: hvor lenge den var våken og hvor stor den var mens den var våken.

Det estimatet bommet på

Vår opprinnelige måler gjorde en antagelse: for hver time en publisert apps server kjørte, belastet vi for en database i den minste beregningsstørrelsen.

Det var feil på tre måter:

1. Størrelsen var feil. Databasene kjørte faktisk med en større standardstørrelse enn estimatet forutsatte.
2. Databaser skalerer automatisk. Under belastning vokser de, og estimatet så aldri det.
3. Databasene følger ikke appserveren. En database forblir våken så lenge noe som helst spør den: appen, en planlagt jobb, et skript som spør den jevnlig. Det skjer uavhengig av om appens server var oppe.

Nettoeffekten var at estimatet belastet brukerne omtrent halvparten av det databasene faktisk kostet. Det er ikke bærekraftig for oss, og det gjorde også at bruksstallene i appen ikke betydde det folk trodde.

Måling i stedet for gjetning

Databaseleverandøren vår rapporterer hvert prosjekts beregningsenhet-sekunder per time, altså hvor mye beregning som faktisk ble brukt, størrelse inkludert. Måleren fungerer nå slik:

1. For hver publisert app med en database henter vi målt bruk for hver ferdige time siden appen gikk live.
2. Vi regner bruken om til kostnad etter leverandørens pris, bruker planens sats og belaster eierens kreditter.
3. Vi ser tilbake opptil ett døgn hver gang, slik at timer som ble oversett mens API-et vårt startet på nytt, fortsatt faktureres senere.

Lagring faktureres separat, etter størrelse, fordi den ikke avhenger av aktivitet.

Aldri belaste en time to ganger

En faktureringsmåler som kjører på mer enn én server, og som kan krasje og forsøke på nytt, må være forsiktig så den ikke dobbeltbelaster. Hver time for hver database reserveres i sin egen databaseraden før den belastes, med en unikhetsbegrensning på paret (database, time). Hvis to servere, eller et nytt forsøk, prøver å fakturere samme time, lykkes bare én reservasjon.

Vi tok også et bevisst valg for det sjeldne feiltilfellet. Hvis prosessen krasjer mellom at en time er reservert og at den er belastet, forblir timen reservert og ufakturert. Å miste en liten del av inntekten ved et sjeldent krasj er bedre enn å belaste noen to ganger.

Og da målt fakturering ble slått på, startet den fra neste hele time. Timene før det var allerede belastet av det gamle estimatet, og å fakturere dem igjen fra målte data ville belastet den perioden to ganger.

Hva dette betyr hvis du bygger på Mythex

• Databaseregningen din speiler det databasen din gjorde. En app som sjelden brukes, koster svært lite. En app som spør databasen hele tiden, holder den våken og koster mer.
• Det største grepet er hvordan appen din bruker databasen. Å spørre databasen hvert par sekund holder den våken døgnet rundt. Å be AI-en hente data ved behov, eller mellomlagre dem, lar databasen sove. Vår guide om hva en database er dekker grunnlaget.
• Pro-planer betaler halvparten av Free-satsen for hosting, databaser og lagring. Detaljene står i kreditt-dokumentasjonen.

Det vi tok med oss

• Estimater av bruksbasert kostnad glir over tid. Når leverandøren oppstrøms kan fortelle hva som ble brukt, fakturer ut fra det.
• Gjør fakturering idempotent på den minste enheten du belaster. For oss er det én database-time.
• Når du må feile, feil til kundens fordel.