Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've just started working on an existing application that uses an LDAP directory service as its object store instead of a database. Many of my coworkers have been commenting how an application should never use a directory service instead of a database as its object store. I've got to work on it regardless, and won't be able to change it from LDAP to a database anytime soon.

That said, my coworkers comments brings up the question in my mind: Why is it bad to use a directory provider instead of a database as an object store? Could there ever be cases where this would not only acceptable, but even better than using a database?

share|improve this question
How much writing do you do to this object store? – user40980 Jul 18 '13 at 18:32
Not a huge amount currently, mostly reads. But the modifications I'm making will introduce a lot more writes on the directory – dsw88 Jul 18 '13 at 18:54
You may find the writes to an LDAP to be less than optimal. Consider - LDAP is characterized as a 'write-once-read-many-times' service. That is to say, the type of data that would normally be stored in an LDAP service would not be expected to change on every access. There are suggestions of read:write ratios for LDAP on the order of 1000:1 (for which LDAP is optimized). – user40980 Jul 18 '13 at 18:57
up vote 7 down vote accepted

I also use Active Directory on my corporate website. One of the benefits was that not only our staff shared for the website the same account they use to connect to Windows, but also customers themselves could seamlessly use different services outside the website itself (like be able to connect to some of our servers through Remote Desktop or use SVN, which relies on Active Directory).

Having a single source of truth is always nice, including for user accounts. I wouldn't imagine having to change once per month my Windows password, my SVN password, the password on the corporate website, and five or six other passwords which would appear if we were using different data sources for each of those systems.

This being said, I can see some drawbacks of this approach:

  1. If you don't benefit, like in my case, from having several disparate systems linked to a single Active Directory, I don't see why would one chose AD instead of an SQL database.

  2. One mistake in configuration, and any registered user can also access any of your machines. This is risky.

  3. I would imagine Active Directory being slower than an average SQL database. This being said, I haven't done any profiling and benchmarking to have any evidence of this assertion.

  4. Active Directory is a tree, with a purpose of organizing and grouping entities and assigning permissions to them. For an ordinary website which requires authentication, such structure is an overkill. A simple flat table is largely enough.

  5. Using Active Directory is not an usual thing for a website. When you start developing it, you encounter lots of issues which are not obvious to solve, including the famous error telling that Active Directory is unwilling to process your request, because... well, it's in a bad mood today. Unit-testing the solution is not straightforward too, and there are things which can be easily missed, like the characters you should escape (given that there are two distinct lists) to avoid AD Injection.

  6. I imagine there might be some drawbacks when it comes to configuration and deployment, even if personally, I haven't encountered any.

share|improve this answer

LDAP servers are often used in a web environment and often back user data. Single Sign On is nearly always backed by an LDAP data store. That one should always use a (relational) database rather than other data stores is... poor.

The key with any data store is to use the one that is most appropriate for the data. Sometimes the data fits better in a traditional database, sometimes it is best in a nosql style data store, other times its a directory. One should use the appropriate data store for the data.

The thing that LDAP excels at is fast lookups for rarely changing data. Going back to the user data (as an example), the email, password, name, and roles rarely change.

Similarly, cached data often fits well into a directory where you compute the data and then load it (which is then frequently read).

Directories, however, don't like frequently updating data. Its a trade off - you can optimize for reads if you penalize writes. Rebuilding indexes on the fly is not something that LDAP does well when comparing it to a relational database.

How (and how well) transactions work are still within flux within LDAP. If you want to have multiple updates be a single atomic operation, this may cause problems.

Referential integrity (foreign keys, unique constraints) does not exist within LDAP. Similarly, if this is what you need, you may find it difficult.

While one could pack JSON data into a field within LDAP, LDAP itself doesn't try to do the data structures that are present in other databases.

If you are doing a not-occasional number of writes or updates (and thus impacting performance), 'joins' of data rather than filters, or want faster consistency than ldap replication offers you may find that LDAP data store is not appropriate.

But as a data store for stuff that rarely changes, it is often one of the best.

share|improve this answer

A directory is a database, although one you don't use SQL to access. So, just call it a NoSQL database and you're cool again!

The only constraint would be that on a directory the data structures (the schema) are fixed, so they might not be adequate for most cases. But if you can express your problem space in that structure, then it could be just as good.

share|improve this answer
You may like to incorporate which argues your calling LDAP a NoSQL database into your answer. – user40980 Jul 19 '13 at 17:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.