Introduction

The databases directive controls the number of logical databases available inside a Redis server.

Unlike traditional relational databases, Redis databases are not separate storage engines. Instead, they are independent namespaces within the same Redis instance.

Each database contains its own keys, allowing applications to separate data without running multiple Redis servers.

This guide explains how Redis databases work, how to configure them, and recommended usage patterns.

Default Value

The default Redis configuration provides:

databases 16

This creates:

Database 0

Database 1

Database 2

...

Database 15

The default selected database is:

Database 0

Syntax

databases

Examples:

databases 16

databases 32

databases 1

How Redis Databases Work

Redis databases are logical containers inside a single Redis server.

Example:

Database 0

user:1001

session:abc123

Database 1

cache:homepage

cache:products

Keys in different databases do not conflict.

The key:

user:1001

can exist in both database 0 and database 1.

Selecting a Database

Redis clients connect to database 0 by default.

To switch databases:

SELECT 1

Example:

redis-cli

127.0.0.1:6379> SELECT 2

OK

Now commands operate on database 2.

Check Current Database

Redis CLI displays the current database number.

Example:

127.0.0.1:6379[2]>

The number inside brackets indicates the selected database.

Configure databases

Edit the Redis configuration file.

sudo nano /etc/redis.conf

Change:

databases 16

Example:

databases 32

Restart Redis:

sudo systemctl restart redis

Verify Configuration

Run:

redis-cli CONFIG GET databases

Example output:

1) "databases"

2) "32"

List Database Usage

Redis provides database statistics through:

redis-cli INFO keyspace

Example:

Keyspace

db0:keys=1500,expires=200

db1:keys=300,expires=50

This shows how many keys exist in each database.

Flush a Specific Database

Delete all keys from the current database:

FLUSHDB

Example:

SELECT 1

FLUSHDB

Only database 1 is cleared.

Flush All Databases

Remove all keys from every database:

FLUSHALL

Warning:

This operation deletes all Redis data.

When Should You Use Multiple Databases?

Multiple databases can be useful for:

Development and testing separation.

Small applications with simple environments.

Temporary data isolation.

Example:

Database 0

Production data

Database 1

Testing data

Database 2

Cache data

When Should You Avoid Multiple Databases?

For large production systems, multiple databases are often discouraged.

Reasons:

Limited access control between databases.

Harder monitoring.

Poorer isolation.

More complex application management.

Many modern applications prefer:

Separate Redis instances.

Different Redis clusters.

Key prefixes.

Example:

app1:user:1001

app2:user:1001

instead of separate databases.

##Common Mistakes

Treating Redis Databases Like MySQL Databases

Redis logical databases are not equivalent to independent SQL databases.

They share:

Memory.

Configuration.

Server resources.

Using Too Many Databases

Creating hundreds of databases does not improve performance or isolation.

Forgetting Database Selection

Applications may accidentally read or write data from the wrong database if the connection configuration is incorrect.

Best Practices

Use database 0 for most simple deployments.

Keep the number of databases small.

Prefer key prefixes for large applications.

Use separate Redis instances when strong isolation is required.

Monitor key usage with INFO keyspace.

Related Articles

Redis Explained

Redis bind Explained

Redis requirepass Explained

Redis maxmemory Explained

Redis key management Explained

Conclusion

The databases directive controls the number of logical databases available in a Redis instance. While multiple Redis databases provide a simple way to separate data, they do not provide the same isolation as independent database servers.

For small applications and development environments, multiple databases can be convenient. For larger production systems, using separate Redis instances or key namespaces is usually a more scalable and maintainable approach.