Last checked and updated on 10 Jun 2026
What Is New in MongoDB 1.3
MongoDB 1.3 introduces significant enhancements focused on performance and operational control. This release delivers faster index creation, more granular locking, and improved sharding support. Here's a quick summary of the key changes.
| Category | Key Changes |
|---|---|
| New Features | Sharding Support, db.eval() |
| Performance | Faster Index Builds, Database-Level Locking |
| Operations | New --shardsvr Option, Compact Command |
| Deprecations | 32-bit Builds (Deprecation Warning) |
How did performance improve in 1.3?
Index builds are now up to 20 times faster, a massive win for anyone dealing with large datasets. This was achieved by optimizing the algorithm to build the index in memory before writing it to disk.
We also moved from a global lock to database-level locking. This means operations on different databases can run concurrently, reducing contention and improving overall throughput. It's a solid step towards more granular concurrency control.
What sharding features were added?
This release marks the initial introduction of sharding support, a foundational feature for horizontal scaling. You can now configure a MongoDB instance to run as a shard server using the new --shardsvr command-line option.
In practice, this is the first building block for distributed clusters. While the full auto-sharding logic came later, 1.3 lays the groundwork by allowing individual shard nodes to be identified and managed.
What new commands can I use?
The compact command was added to defragment and reclaim disk space from a collection. This is useful for cleaning up after large deletions without having to resort to a full repairDatabase.
We also got db.eval(), which allows executing JavaScript code on the database server. This can be powerful for complex atomic operations but use it cautiously as it holds a write lock for the duration of execution.
Are there any warnings for future changes?
Yes, 1.3 started issuing deprecation warnings for 32-bit builds. The writing was on the wall due to the inherent memory limitations of 32-bit systems, which are a poor fit for database workloads. This was a clear signal to start migrating to 64-bit infrastructure.
FAQ
Is the faster index building safe to use in production?
Yes, the new index build process is stable. It builds the index in memory first, making it faster and reducing the time your collection is locked. This matters because it minimizes the operational impact of adding indexes to large collections.
Does database-level locking mean no more global lock?
No, the global lock is gone for operations across different databases. However, operations within the same database still contend for that database's lock. It's a major improvement, but not full collection-level locking yet.
Can I start sharding my data with just 1.3?
Not really. Version 1.3 introduces the concept of a shard server (--shardsvr), but it lacks the config servers and mongos router needed for automatic data partitioning. This is the foundational plumbing for the full sharding system that came later.
When should I use db.eval()?
Use db.eval() sparingly for complex atomic scripts that need to run on the server. Be aware that it blocks other operations on that database, so avoid long-running scripts. For most cases, standard CRUD operations are a better choice.
Should I be worried about the 32-bit deprecation warning?
You should take it seriously and plan a migration. 32-bit systems are limited to around 2GB of data, which isn't practical for most database use cases. The 64-bit version doesn't have this limitation and is the future of the platform.