Scale down with Compose and Import improvements: Noteworthy at Compose

Published

This is your weekly summary of Compose news for those changes and updates which can make your life easier. In this edition, we give a quick refresher about scaling down Compose database deployments, locking down database imports and we review last weeks Compose articles.

Scaling on Compose

It's been a quiet week for features and enhancements but we did notice an uptick in users who aren't aware of the detail how auto-scaling up and scaling down works on Compose. So here's a quick refresher on how we do it.

Scale is about capacity

The first rule of scale club at Compose is "Database deployments can scale up automatically but they have to be scaled down manually". This is deliberate because, in our experience, reducing the scale of a database needs human oversight. We increase capacity automatically - or let you add capacity and we let you decide when to reduce capacity.

The thing to know is that a Compose database deployment's allocated resources are independent of how much data is stored in it. We bill by those allocated resources. A database deployment's scale is its resource capacity available to be used without triggering automatic scaling and it represents the high water mark of how much data has been stored in the database.

We know that for a number of workloads, the storage of the database first hits that high water mark, then sinks back, then rises and repeats. That means automatically reducing the scale can put your database into a situation where it needs to scale and not-scale at the same time.

Freeing up space

There's also, with some databases, the issue that they don't naturally shrink on disk. MongoDB, for example, will not release disk storage back to the system unless it's made to release it. Just deleting collections from the database will reduce the amount of data held by the database, but it won't reduce the disk usage. To do that on Compose (and any MongoDB with replica sets) you need to resync the deployment to make each node give up its unused disk space. We've got documentation on resyncing and how to scale down safely and effectively.

It's generally simpler for other databases. We have scaling down help that can be found the various Resources and scaling pages for all the databases: PostgreSQL, Elasticsearch, Redis (which only auto-scales in storage mode), RabbitMQ, etcd 3, Scylla, MySQL and JanusGraph.

Locking down imports

Users are able to import into MongoDB databases from other Compose MongoDB databases in the same account. It's a popular feature which many Compose users make use of and thanks to an observant user, it's now more secure. That user spotted that with particular combinations of teams and roles it was possible to import databases from the same account when the teams and roles should have prevented it.

We've fixed that issue now and locked down the import feature so it strictly uses the current users role within the account. Some users may find they can no longer import from their accounts other databases. We recommend those users are either given sufficient privilege to access the other databases or a user with higher privileges carries out the import.

Compose Articles

Last week, Compose Articles dived into the log API, Write Stuff returned with the first article of 2018 and NewsBits covered the news that MongoDB Inc was creating its own Go driver.

That's it for this week's Noteworthy at Compose. Onwards to next week!


Read more articles about Compose databases - use our Curated Collections Guide for articles on each database type. If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at articles@compose.com. We're happy to hear from you.

attribution David Clode

Dj Walker-Morgan
Dj Walker-Morgan is Compose's resident Content Curator, and has been both a developer and writer since Apples came in II flavors and Commodores had Pets. Love this article? Head over to Dj Walker-Morgan’s author page to keep reading.

Conquer the Data Layer

Spend your time developing apps, not managing databases.