Stop Tying Down MySQL! The Ultimate Guide to Nacos Embedded Derby Solutions and Database Selection

When you are struggling locally with Nacos and exclaim, “Installing MySQL, configuring master-slave, changing ports… I just want to run a demo locally!” In fact, 90% of developers do not know: you can start Nacos with zero dependencies without installing MySQL—the secret lies in the embedded database Derby.

1. Derby: The Overlooked King of Embedded Databases

1. The Origin and Development of Derby

• 1996: Cloudscape, Inc. was founded in the USA, aiming to develop a lightweight database based on Java, designed to provide embedded data storage solutions for Java applications.
• 1997: The first commercial version of the database was released, named Cloudscape, featuring zero management and easy integration, becoming an important component of the early Java ecosystem.
• 1999: Cloudscape was acquired by database giant Informix Software, continuing to iterate as a commercial product.
• 2001: Informix was acquired by IBM, and Cloudscape became part of IBM’s product line, renamed IBM Cloudscape™, widely used as an embedded database in IBM software (such as WebSphere).
• Technical Accumulation: By this time, Cloudscape had accumulated nearly 500,000 lines of Java code, laying the technical foundation for future open-sourcing.
• April 2004: IBM donated the Cloudscape code to the Apache Software Foundation, and the project was renamed Apache Derby, entering the open-source incubation phase.
• July 2005: Completed incubation and officially released Apache Derby 1.0, becoming an Apache top-level project.
• 2005-Present:

• Sun Microsystems (now Oracle) integrated Derby into the Java SE development kit (Java DB), as the officially recommended embedded database.
• Supports SQL-92/SQL:2003 standards, ACID transactions, stored procedures, and other advanced features. Compatible with JDBC 3.0/4.0, seamlessly connecting to Java applications.
• Application Scenarios: Became the first choice for lightweight applications, such as development testing environments (like the Maven plugin derby-maven-plugin); desktop applications (like the default storage for Cognos BI).

2. Essence Revealed: SQL Engine + File Repository

Derby is not a traditional database service! It is essentially a Java embedded database engine that adheres to SQL standards, implementing structured data storage through the file system! It is a pure Java SQL toolkit that can store data in local files:

# Derby storage structure (in project directory)
./my_data/ 
   ├─ seg0/      # Actual data files
   ├─ log/       # Transaction logs
   └─ service.properties

Nacos uses Derby as the default database, and when starting Nacos, there is no need to modify the MySQL-related configurations in the configuration file, allowing for:

• No need to install any database service
• Data is automatically stored in the project directory
• Standard SQL operations (90% similarity to MySQL syntax)

Core Positioning: Standalone lightweight data engine

3. Derby vs. MySQL: A World Apart in Positioning

Capability	Derby	MySQL
Startup Speed	⚡️ 0.5 seconds (embedded application process)	⏱ 5-30 seconds (requires independent service startup)
Data Storage	📁 Local file directory	💾 Independent database file system
Maximum Connections	10-20 (single process)	1000+
Applicable Scenarios	Development testing/Standalone deployment	Production clusters/High concurrency

2. Derby Practice in Nacos: A Minimalist Solution to Abandon MySQL

1. Configuration Process (Three Simple Steps)

The official Nacos downloaded by the author does not require any configuration modifications to start; it defaults to using the Derby database, generating a data directory in the installation directory.

Step 1: Modify application.properties

# Key configuration: Use embedded Derby
spring.datasource.platform=derby  

# Data storage location (data/derby-data generated in the current directory)
db.num=1
db.url.0=jdbc:derby:${nacos.home}/data/derby-data;create=true

Step 2: Remove MySQL dependencies (to avoid conflicts)Remove from pom.xml:

&lt;!-- Remove this! --&gt;
&lt;dependency&gt;
    &lt;groupId&gt;mysql&lt;/groupId&gt;
    &lt;artifactId&gt;mysql-connector-java&lt;/artifactId&gt;
&lt;/dependency&gt;

Step 3: Start Nacos

# Run directly (no MySQL errors in console)
sh startup.sh -m standalone

2. Working Principle Diagram



Nacos Application
Derby.jar
Local file directory
Read and write data

Data Viewing Tips: After running Nacos, visit http://localhost:8848/nacos ➔ Configuration List ➔ Export All Configurations The exported .zip file is a snapshot of the configurations stored in Derby.

3. When Should You Use Derby? When Must You Use MySQL?

Derby Applicable Scenarios (Development/Testing/Standalone)

1. Local Development Debugging

• Fast startup: Saves time on MySQL installation and configuration
• Zero dependencies: New colleagues can clone the code and run it immediately

2. Standalone Demonstration Environment

• Runs on a cloud server with 1 core and 1GB of small resources
• Quickly validate functionality (POC)

3. CI/CD Pipeline Testing

• Automatically start Nacos + Derby for integration testing

# Jenkins Example
- script: 
    sh startup.sh -m embedded

MySQL Irreplaceable Scenarios (Production Must)

1. Multi-node Cluster Deployment

• Derby does not support multi-machine data synchronization
• Nacos clusters need to share the same MySQL database

2. Configuration Security Persistence

• Derby data is stored on local disk, lost if the server is damaged
• MySQL supports off-site backup/RDS high availability

3. Hundreds of Services Registration

• Derby single process cannot handle high concurrency writes

Performance Threshold Reference Values:

• Derby limit: 50 services/200 configuration items
• MySQL recommendation: 100+ services/1000+ configuration items

4. Can Nacos Use Other Databases?

Of course! Nacos adopts a multi-data source plugin architecture, supporting:

Database	Configuration Example	Applicable Version
Derby	spring.datasource.platform=derby	All versions
MySQL	spring.datasource.platform=mysql	All versions (default)
PostgreSQL	spring.datasource.platform=postgresql	v2.2+
Oracle	spring.datasource.platform=oracle	Enterprise Custom Version

It even supports TiDB distributed databases!

# TiDB configuration adaptation
db.pool.config.driverClassName=com.mysql.cj.jdbc.Driver
db.url.0=jdbc:mysql://tidb-cluster:4000/nacos

5. Decision Guide: Understand How to Choose

Standalone/Testing
Production/Cluster
Data Volume >1TB
High Concurrency Requirements
Startup Requirements
Derby
MySQL
Sharded MySQL Cluster
TiDB/PostgreSQL

General Rules:

1. Run on development laptops → Derby
2. Demonstration environment virtual machines → Derby
3. Online production deployment → MySQL/PostgreSQL
4. Ultra-large scale systems → TiDB cluster

Conclusion: Return to Simplicity

When you restart the service for the fifth time due to MySQL startup failure, remember Derby, this silent partner—it may not be suitable for vast oceans, but it is always the strongest fallback solution for local development.