Jeg har set dette før med en klient, der ringede til mig for at få nødhjælp.
Efter at have kikket lidt rundt med heroku bash vi konkluderede til sidst, at den nye instans var på en særlig travl underliggende server. Vi lavede en failover via follower-promovering til en anden maskine, på hvilket tidspunkt ydeevnen blev væsentligt forbedret - selvom failoveren i sig selv var udfordrende på grund af problemerne med masteren.
Så vidt jeg ved, er Herokus forekomster Amazon EC2 noder (Xen VM'er), der kører en LXC container for at isolere hver Heroku brugers databaseklynger. LXC tilbyder noget mindre isolation end en fuld VM gør; instanser kan kæmpe om RAM, disk I/O, CPU osv., afhængigt af den nøjagtige politik, der er konfigureret med OpenCZ, eventuelle kontrolgruppepolitikker osv.
Hvis du er på en instans, hvor de andre brugere ikke gør meget, og hvis containeren tillader din DB at bruge ressourcer, der i øjeblikket ikke kræves af andre brugere, kan du nemt se en konstant højere ydeevne end garanteret.
Jeg formoder, at folk med større heroku-planer er mere tilbøjelige til rent faktisk at bruge ressourcerne i det system, du deler en container med.
Hvis du laver en kampagnefailover til en større instans, hvor alle brugerne er der, fordi de virkelig har brug for de ressourcer, der tilbydes af den større maskine, kan du faktisk få mindre ressourcer overordnet, fordi alle rent faktisk bruger deres aktier.
Det er frustrerende, at Heroku tilbyder så lidt synlighed i de systemer, der kører deres DB'er. Det er svært at sige, hvordan/om de belaster balance mellem containerværter, hvad den underliggende belastning på systemet er osv.
I en kommentar påpegede @Forrest, at Heroku har en nyttig side på deres serveroplysninger , hvilket viser, at kun de lavere niveauer er multi-lejer, men højere niveauer er det ikke. Dette ville nemt forklare det ydelsestab, der blev observeret her, og ville passe ind i mine kommentarer ovenfor om, at den lavere plan tillod Forrest at låne ubrugte ressourcer fra andre brugere.