1. LDAP is mostly picked over Database if the read/write ratio is more than 10,000/1 (this number is bit arguable) - since its more optimized for read operations. So in general LDAP is more preferred for static data.
2. LDAP has scalability concerns - even Microsoft recommends MS SQL server over Active Directory - if the user base is more than 1.5 million. In most of the large scale deployments I am aware of Database is preferred over LDAP. There are some cases where people use MySQL to handle 60 million users. Some US state governments use MS SQL server to manage citizens. So, the rule-of-thumb is if the user base is less than 1 million then LDAP should fine. But, if it exceeds that then better to go ahead with a proven Database. Also note that more than 90% of Fortune 500 companies use Microsoft Active Directory.
3. LDAP implementations provide more in-built functionalities like, password update/rotation policies, fine-grained access control via ACLs, account locking, groups and etc. If you are using a Database as the user store, then either you need to implement all those by yourself or use a third-party identity management system on top of the Database.
4. LDAP has inbuilt support to manage hierarchical relationships between user entities. If this is a requirement, and go for a Database - has to be implemented from the scratch.
5. Transactional data related to the user should not be stored in the LDAP. Those have to be maintained in the Database and linked to the LDAP user via entryUUID.
6. LDAP has inbuilt support for multi-valued attributes. Say someone can have multiple email addresses - phone numbers - LDAP by design supports keeping multiple values against the same attribute. If this is a requirement and go for a Database - has to be implemented from scratch.
7. LDAP has an inbuilt security model over the data it stores. You can define ACLs over attributes and sub-trees. We don't find this in a Database and has to be implemented from scratch.
8. Both in LDAP and JDBC, the schema can be extended.
9. Integration with third-party applications is much flexible with LDAP - since its a standard
2. LDAP has scalability concerns - even Microsoft recommends MS SQL server over Active Directory - if the user base is more than 1.5 million. In most of the large scale deployments I am aware of Database is preferred over LDAP. There are some cases where people use MySQL to handle 60 million users. Some US state governments use MS SQL server to manage citizens. So, the rule-of-thumb is if the user base is less than 1 million then LDAP should fine. But, if it exceeds that then better to go ahead with a proven Database. Also note that more than 90% of Fortune 500 companies use Microsoft Active Directory.
3. LDAP implementations provide more in-built functionalities like, password update/rotation policies, fine-grained access control via ACLs, account locking, groups and etc. If you are using a Database as the user store, then either you need to implement all those by yourself or use a third-party identity management system on top of the Database.
4. LDAP has inbuilt support to manage hierarchical relationships between user entities. If this is a requirement, and go for a Database - has to be implemented from the scratch.
5. Transactional data related to the user should not be stored in the LDAP. Those have to be maintained in the Database and linked to the LDAP user via entryUUID.
6. LDAP has inbuilt support for multi-valued attributes. Say someone can have multiple email addresses - phone numbers - LDAP by design supports keeping multiple values against the same attribute. If this is a requirement and go for a Database - has to be implemented from scratch.
7. LDAP has an inbuilt security model over the data it stores. You can define ACLs over attributes and sub-trees. We don't find this in a Database and has to be implemented from scratch.
8. Both in LDAP and JDBC, the schema can be extended.
9. Integration with third-party applications is much flexible with LDAP - since its a standard