Jag har sett det här förut med en klient som ringde mig för akut hjälp.
Efter att ha letat runt med heroku bash vi drog så småningom slutsatsen att den nya instansen var på en särskilt upptagen underliggande server. Vi gjorde en failover via follower-förflyttning till en annan maskin, då prestandan förbättrades avsevärt - även om failoveren i sig själv var utmanande på grund av problemen med mastern.
Så vitt jag vet är Herokus instanser Amazon EC2-noder (Xen VM) som kör en LXC-behållare för att isolera varje Heroku-användares databaskluster. LXC erbjuder ganska mindre isolering än en komplett virtuell dator gör; instanser kan tävla om RAM, disk I/O, CPU, etc, beroende på den exakta policyn som konfigurerats med OpenCZ, eventuella kontrollgruppspolicyer, etc.
Om du är på en instans där de andra användarna inte gör så mycket och om behållaren tillåter din DB att använda resurser som för närvarande inte krävs av andra användare, kan du lätt se stadigt högre prestanda än garanterat.
Jag misstänker att personer med större Heroku-planer är mer benägna att faktiskt använda resurserna i systemet du delar en container med.
Om du gör en kampanjfailover till en större instans där alla användare är där eftersom de verkligen behöver resurserna som erbjuds av den större maskinen kan du faktiskt få mindre resurser överlag, eftersom alla faktiskt använder sina andelar.
Det är frustrerande att Heroku erbjuder så lite insyn i systemen som kör deras DB:er. Det är svårt att säga hur/om de lastar balans mellan containervärdar, vad den underliggande belastningen på systemet är osv.
I en kommentar påpekade @Forrest att Heroku har en användbar sida på sin serverinformation , vilket visar att endast de lägre nivåerna är flerhyresgäster, men att högre nivåer inte är det. Detta skulle lätt förklara den prestandaförlust som observerats här, och skulle passa in i mina kommentarer ovan att den lägre planen tillät Forrest att låna oanvända resurser från andra användare.