What Is an OpenLDAP Backend?
In OpenLDAP, a backend defines the core data engine that slapd (the LDAP server daemon) uses to fulfill directory operations. The backend determines whether your directory data is read from a local on-disk database, proxied from another LDAP server, dynamically generated, or handled in a specialized way.
It’s common to see confusion between “backend” and “database” in OpenLDAP documentation and discussion. A backend is a particular storage or proxy engine (such as back-mdb or back-ldap). A database is a configured instance of slapd that uses a backend to manage a segment of the directory information tree (DIT). Multiple databases can use the same backend type, each operating on different directory suffixes or namespaces, but each database instance is configured separately within slapd.
This distinction matters: choosing the right backend is foundational, directly affecting performance, operational complexity, scalability, and your ability to upgrade or maintain your service.
Categories of OpenLDAP Backends
OpenLDAP backends fall into three broad functional categories:
- Storage backends: Engines that manage persistent data, storing and retrieving directory entries on local disk.
- Proxy backends: Components that forward LDAP operations to external LDAP servers, effectively turning slapd into a proxy, router, or gateway.
- Special-purpose or dynamic backends: Engines that do not store normal directory data but provide dynamic or synthetic responses—for monitoring, mapping system users, generating no data, or other niche functions.
The category matters both for operational suitability and for understanding which backends are appropriate for directory data versus integration or auxiliary roles. A proxy backend, for example, does not store data locally; it relays operations to other servers and may introduce complexity around access control and consistency.
Inventory of Backend Types and Status
Below is a concise rundown of the principal OpenLDAP backend types, their purposes, and their support status in modern OpenLDAP releases:
Core Storage Backends
- back-mdb (recommended): Uses the MDB (Memory-Mapped Database) engine; fast, scalable, transactional, and reliable. Officially supported and actively maintained; suitable for all new production deployments.
- back-ldif: Stores each LDAP entry as a separate LDIF file on disk. Simple and human-readable, but offers low performance and is intended mainly for testing or config storage, not production.
Deprecated Storage Backends
- back-bdb and back-hdb: Based on Berkeley DB. Once popular, now deprecated due to technical and licensing issues. Unsupported and unsafe for new deployments.
- back-ldbm: Superseded by back-bdb and back-hdb years ago; should not be used.
Proxy and Hybrid Backends
- back-ldap: Proxies LDAP operations to another LDAP server. Useful for integration, virtualization, centralizing access, or directory consolidation.
- back-meta: Extends back-ldap by allowing slapd to proxy and aggregate across multiple remote LDAP servers, supporting referral chasing and advanced routing.
Special-Purpose Backends
- back-monitor: Exposes internal slapd and backend statistics as a dynamic subtree, useful for monitoring.
- back-null: Discards all operations; useful for testing, development, or load balancing scenarios where no persistent data is required.
- back-passwd: Maps POSIX system /etc/passwd users as LDAP entries; not for general-purpose directory deployment.
- back-shell and back-perl: Allow handling of LDAP operations via shell scripts or embedded Perl code; specialized, experimental, and not for typical directory storage.
Most special-purpose and experimental backends are meant for integration, demonstration, or internal slapd use—not as a mainline storage strategy.
Comparing Backends: Strengths and Limitations
Storage Backends
- back-mdb is now the gold standard—a robust, high-performance transactional engine requiring minimal tuning. It is scalable, reliable, and well-documented, with a straightforward migration and upgrade path. It uses memory-mapped files and requires careful planning of database size but greatly reduces historic operational issues seen with BDB-based engines.
- back-ldif offers an extremely simple data model—one LDIF file per entry—but cannot match the concurrency, search performance, or reliability guarantees required for production directories.
Storage backends like back-mdb are required for deployments where data lives on the local slapd server and must survive restarts and crashes.
Proxy Backends
- back-ldap and back-meta do not store directory data. Instead, they forward requests to designated target LDAP servers. They are essential in architectures where consolidation, virtualization, or load-routing is required, or for integrating multiple directories under a unified view.
- Proxy backends introduce complexity: access control, schema mapping, authentication, and consistency all depend on the behavior of the remote server and the slapd frontend configuration. These backends can be fine-tuned (especially back-meta) for advanced routing but should not be mistaken for a drop-in storage replacement.
Deprecated Backends
- back-bdb and back-hdb were widely used but are now deprecated due to licensing and technical debt. They are no longer supported in new OpenLDAP releases and lack fixes for known issues. Their use now carries significant risk—production deployments should migrate to back-mdb.
Special and Experimental Backends
Special-purpose backends should only be used for their intended test, monitoring, or system integration roles. They are not suitable for scalable, production-grade directory storage.
Choosing the Right Backend: Best Practices and Pitfalls
For new OpenLDAP deployments, the recommended storage backend is clear: back-mdb. It has superseded back-hdb and back-bdb, offering faster operations, improved robustness, and long-term support. For use cases involving proxying or consolidation of multiple directories, back-ldap (for single targets) and back-meta (for multi-target, advanced proxy scenarios) are suitable.
A few guiding principles:
- Do not use deprecated storage backends (back-bdb, back-hdb, back-ldbm) for new systems. Their future removal from OpenLDAP is planned; they no longer receive maintenance.
- Migrating an existing OpenLDAP deployment from bdb or hdb to mdb is a full data migration. This typically requires exporting the directory to LDIF format, reconfiguring slapd, and reimporting the data. There is no in-place backend engine switch.
- Proxy backends are not simple substitutes for storage. They bring requirements around referral, authentication, and schema alignment that must be planned for explicitly.
- Hybrid or multi-backend deployments are possible: for example, serving different directory subtrees from local storage, proxy backends, or special monitoring trees. Each is a configured database in slapd, with a dedicated backend type.
Build your backend selection on the real needs of your deployment: performance, reliability, security, and maintainability in the context of the directory’s role.
Configuration, Loading, and Further Resources
In modern OpenLDAP, backends can be compiled directly into slapd or—more commonly—loaded as dynamic modules. Modules are loaded at startup by referencing them in your configuration. Each database section in slapd references a backend by name (such as mdb, ldif, ldap, or meta). The specific backend module must be present and loaded for slapd to instantiate the corresponding database.
Authoritative and version-specific backend configuration guidance is available directly in the official OpenLDAP Administrator’s Guide and FAQ. For the most accurate information and working configuration examples, always refer to the OpenLDAP documentation matching your slapd version. These documents enumerate supported backends, their recommended uses, caveats, and migration instructions—with links to in-depth configuration and tuning documentation.
Sources:
- OpenLDAP Software 2.5 Administrator's Guide: Backends
- OpenLDAP Software 2.4 Administrator's Guide: Backends
- OpenLDAP Faq-O-Matic: What are the different backends? What are their differences?
- OpenLDAP Faq-O-Matic: What is a backend?
- OpenLDAP Faq-O-Matic: Overlays