Defending A Single Shared Database Instance

Let’s say for some reason you ended up with a single, shared database instance that supports many microservices instead of having one database instance per service. Don’t worry, it happens to all of us.

One reason this might happen is to save money. It’s cheaper in terms of infrastructure costs to have a single, large, database instance than to have many small ones generally. Of course, this doesn’t account for the tradeoffs in the overhead of maintaining many instances over a single one. However, it also doesn’t take into account the many engineering months/years it’ll take in the future to split out the databases.

Unlike Kubernetes or EKS, there aren’t as many controls in place for databases to defend against noisy neighbors. Noisy neighbors are other processes running on the shared resources that can affect your workload. For example, with Kubernetes, you can set CPU/Memory requests and limits. There’s no great way to set database limits per user. On AWS with Aurora, the primary metrics I’ve seen as bottlenecks are the number of database connections a database user consumes, and the number of active sessions.

Database connections are consumed by your services’ database connection pools. Database sessions are a more confusing metric.

Here’s an AI-generated definition:

An active database session, in the context of Amazon Aurora or any other database system, refers to a currently open and active connection between a client application and the database. It represents an ongoing interactive information exchange between the client and the database server.

An active database session is usually a process that executes a query. This isn’t always the case but it’s a good enough mental model.

Tomorrow, I’m going to go into how we’re working on tackling an aspect of the problem.

If you have a large shared database, how would you defend it against noisy neighbors?

---