FISCO BCOS is a leading enterprise-grade blockchain platform that enables developers to build high-performance, secure, and scalable decentralized applications. One of its standout features is the CRUD (Create, Read, Update, Delete) functionality—a powerful tool designed to simplify blockchain application development by introducing familiar database-like operations into the smart contract environment.
This guide walks you through the core concepts, benefits, implementation methods, and best practices for using CRUD in FISCO BCOS, helping you develop blockchain applications more efficiently while maintaining high performance and flexibility.
Why Was CRUD Designed?
In FISCO BCOS 1.0, data was stored locally using the MPT (Merkle Patricia Trie) structure with LevelDB as the underlying storage engine. While secure and tamper-proof, this approach had limitations: storage capacity was constrained by disk size, data could grow rapidly with increasing business volume, and migrating or managing large datasets became complex and costly.
To overcome these bottlenecks, FISCO BCOS 2.0 introduced a distributed storage architecture based on a table-based schema. This shift not only improved scalability and performance but also paved the way for a new development paradigm—CRUD operations on blockchain data. By modeling data in tables and supporting SQL-like interactions, CRUD makes blockchain development more intuitive for traditional developers.
👉 Discover how modern blockchain platforms streamline data operations
Key Advantages of CRUD in FISCO BCOS
The CRUD system in FISCO BCOS delivers what developers need most: simplicity, speed, and maintainability. Its design follows the principle of "two improvements and two reductions"—enhancing efficiency and performance while reducing maintenance complexity and migration costs.
Boost Development Efficiency
CRUD allows developers to treat smart contracts like stored procedures in a traditional relational database. Instead of manually encoding complex data logic in Solidity, you can perform standard table-based operations—inserting rows, querying entries, updating records, or deleting data—using clean, readable code. This significantly lowers the learning curve and accelerates development cycles.
Enhance Application Performance
Under the hood, CRUD operations are powered by precompiled contracts, which execute directly in native code rather than going through the slower Ethereum Virtual Machine (EVM). This means read and write transactions are processed at high speed, resulting in faster consensus and lower latency—critical for enterprise-grade applications handling high-throughput workloads.
Reduce Contract Maintenance Complexity
With CRUD, business logic is decoupled from data storage. Data resides in shared tables accessible across multiple contracts. When upgrading business logic, you can deploy a new contract version that reads from and writes to existing tables without disrupting historical data. This modularity simplifies upgrades and enhances long-term maintainability.
Lower Migration Costs from Traditional Systems
Many existing enterprise systems rely on SQL databases. Migrating such applications to blockchain used to require complete rewrites. With CRUD, developers can reuse their existing data models and smoothly transition SQL-based business logic onto the blockchain—preserving investment in legacy architecture while gaining immutability and decentralization.
How to Use CRUD: Two Approaches
FISCO BCOS offers two primary ways to interact with CRUD functionality: CRUD Contracts and SDK CRUD Service Interfaces.
Option 1: CRUD Smart Contracts
CRUD contracts are Solidity smart contracts enhanced with table manipulation capabilities via the Table.sol interface.
Step 1: Import Table.sol
Include the official abstract interface:
import "./Table.sol";Step 2: Create or Open a Table
Use TableFactory (located at fixed address 0x1001) to define your schema:
TableFactory tf = TableFactory(0x1001);
int count = tf.createTable("t_test", "name", "item_id,item_name");Note: Table creation is lazy—actual instantiation happens during first use.
Step 3: Perform CRUD Operations
Insert:
Entry entry = table.newEntry(); entry.set("name", name); int result = table.insert(name, entry);Query:
Condition cond = table.newCondition(); Entries entries = table.select(name, cond);Update:
entry.set("item_name", newItemName); int updated = table.update(name, entry, cond);Delete:
int deleted = table.remove(name, cond);
Option 2: SDK CRUD Service Interface
For even faster prototyping or backend integration, use the CRUD Service API provided by FISCO BCOS SDKs (Java, Python, Node.js). These call a built-in precompiled contract directly, eliminating the need to write and deploy custom contracts.
For example, in Java:
CRUDService crudService = new CRUDService(web3j, credentials);
crudService.createTable("t_assets", "asset_id", "owner,value");This method is ideal for scripts, admin tools, or temporary data insertion tasks.
👉 Explore seamless blockchain integration through developer-friendly APIs
Choosing Between CRUD Contracts and SDK Services
| Use Case | Recommended Approach |
|---|---|
| Business logic with validation rules | ✅ CRUD Contracts |
| Direct data insertion/querying without logic | ✅ SDK CRUD Service |
| Accessing non-table state variables | ✅ CRUD Contracts only |
| Rapid testing or console operations | ✅ SDK + Console SQL commands |
While SDK services offer simplicity, they lack the flexibility of full contract logic. For production-grade dApps requiring access control, event emission, or complex workflows, CRUD contracts remain essential.
Best Practices for Effective CRUD Usage
Follow these guidelines to maximize efficiency and avoid common pitfalls:
1. Prefer CRUD Contracts for Production Apps
Unless your use case involves simple data logging or debugging, always opt for CRUD contracts. They provide full programmability and better security controls.
2. Never Modify Table.sol
The Table.sol file contains standardized interfaces with matching implementations in node-level precompiled contracts. Altering it will break execution.
3. Understand That Primary Keys Are Not Unique
Unlike traditional databases, primary keys in CRUD tables are not enforced as unique. Multiple records can share the same key. Always include additional filters when querying to avoid unintended results.
4. Optimize Parameter Handling with Structs
Solidity limits local variables to 16 per function. For tables with many fields, wrap parameters in structs or arrays:
struct Asset {
string id;
string owner;
uint256 value;
}5. Always Reopen Tables Per Method Call
Do not store Table objects as global variables—they are bound to temporary addresses invalidated after each block. Always open the table within each method using tf.openTable().
However, you can safely cache the TableFactory instance since it resides at a fixed address (0x1001).
6. Combine Table Storage with State Variables
You’re not limited to one storage pattern. Use state variables for simple flags or counters, and tables for structured datasets:
uint256 public totalRecords; // State variable
// vs.
// Table for detailed records7. Enforce Table Access Control
Since table data is separate from contract logic, any account could potentially write to it unless restricted. Implement permission control to limit write access to authorized addresses only.
Frequently Asked Questions (FAQ)
Q: Can I use SQL syntax directly with FISCO BCOS?
A: Yes! The FISCO BCOS console supports SQL-like commands for interacting with user tables via CRUD Service, making it easy to test queries and manage data during development.
Q: Are CRUD operations atomic?
A: Yes. Each transaction involving insert, update, or delete is atomic—either all changes succeed or none do, ensuring data consistency.
Q: Is there a limit on table size?
A: No hard limit. Thanks to distributed storage, tables can scale horizontally across nodes, constrained only by network capacity.
Q: Can I query across multiple tables?
A: Not natively. Joins aren’t supported yet. You’ll need to handle multi-table logic within your contract code or application layer.
Q: How are CRUD transactions validated?
A: Like all transactions, CRUD operations go through consensus (e.g., PBFT). Only after validation are changes permanently recorded on-chain.
Q: Can I delete an entire table?
A: Currently, FISCO BCOS does not support dropping tables. Data immutability principles mean once created, tables persist—even if empty.
👉 Learn how leading platforms combine ease-of-use with robust blockchain infrastructure
Final Thoughts
FISCO BCOS’s CRUD functionality bridges the gap between traditional software development and blockchain innovation. By embracing familiar patterns like tables and structured queries, it empowers developers to build robust decentralized applications faster and with greater confidence.
Whether you're migrating an existing system or starting fresh, leveraging CRUD—especially through well-structured contracts—can dramatically improve your development experience.
Core keywords: FISCO BCOS, CRUD, blockchain development, smart contracts, distributed storage, precompiled contracts, table-based blockchain, enterprise blockchain