Neo4j makes multiple databases per instance generally available in AuraDB

One instance, many graphs

According to Neo4j, enterprise graph workloads rarely stop at one database. The company describes a common pattern: a first graph application grows to five, each needing dev, staging and QA environments, and a team ends up managing twenty instances for what is really a handful of workloads.

The problem is sharper for SaaS companies building on Aura. Every tenant needs isolated data, but provisioning a full instance per tenant means paying for compute that sits mostly idle, and each new customer adds infrastructure to size, monitor, patch and pay for. Neo4j says teams moving past their first AI application hit the same wall.

With multiple databases, an AuraDB instance hosts many databases side by side. Each shares the instance's compute and storage but stays separate from the others. Databases can be added or removed and are managed from the Aura API or Console. Neo4j says the feature is included in standard AuraDB instance pricing, regardless of how many databases are run.

Where Neo4j sees it fitting

Neo4j lists several use cases:

• Multi-tenant applications for OEMs and SaaS builders: one database per customer in a shared instance. Onboarding becomes an API call, and restoring one tenant never touches another.
• Agentic applications that need a graph per agent, knowledge domain or application context, up to the database limits for the tier, with access governed through RBAC.
• Departmental and domain separation: a central platform team can offer graph as a service inside an organization, with a database per team or project.
• Workload segmentation: transactional and analytical graphs kept as separate databases that can be backed up, restored and evolved independently.
• Environment consolidation: dev, test, staging and training environments run as databases in a shared non-production instance.

Production features and limits

Neo4j says multiple databases meet the same bar as the rest of AuraDB. Databases are lightweight, so creating one takes seconds, and the full lifecycle can be automated through the Console or the Aura API. Metrics and logs work at the database level, so teams can see what each workload is doing rather than only the instance.

The feature works with the security features of each tier, including single sign-on, IP filtering and private endpoints, as well as standard Neo4j RBAC. Each database has its own backups (ad hoc, hourly and daily), restores and exports.

On scaling, the default is up to 5 databases per GB of RAM. Initially, the limits are up to 250 databases on Virtual Dedicated Cloud and 100 on Business Critical. Bloom, Query, Import and Dashboards operate at the database level, and existing drivers connect by specifying the database name.

What it means for customers

Neo4j says general availability came on September 30, 2026, after a preview period in which customers ran real workloads such as tenant isolation on SaaS platforms and per-domain graphs in enterprises.

The company also points to teams running self-managed Neo4j, where hosting multiple databases in one deployment has long been standard. It says this had been a hurdle when considering a move to Aura, and that teams can now bring an existing multi-database architecture to AuraDB without redesigning it around one instance per database.

To use it, customers create a new AuraDB Business Critical or Virtual Dedicated Cloud instance and enable Multiple databases under Additional settings. The setting is chosen at creation. Neo4j says further enhancements are planned for the coming months.