Les licences de bases de données sont un sujet épineux. Lorsque l'on opte pour un logiciel de base de données d'entreprise, cela implique généralement de prendre deux décisions : choisir l'édition et un modèle de licence. Le choix de l'édition pourra être dicté par l'architecture de la plate-forme matérielle sur laquelle la base de données tournera. Par exemple, si l'on souhaite utiliser un serveur de base de données sous Windows avec plus de quatre processeurs, il faudra opter pour l'édition Entreprise de SQL Server 2008 ; il en va de même pour Oracle 11g. Avec Sybase ASE, par exemple, l'édition Entreprise s'impose si vous anticipez plus de 256 connections simultanées.
Fidèle au genre IBM, le modèle de DB2 est encore plus complexe, avec des restrictions simples (comme la limite de 16 Go de RAM de l'édition Workgroup) associées au concept plus compliqué de PVU, ou Processor Value Unit (Unité de Valeur Processeur) - au lieu de simplement compter le nombre de CPU, la limite est calculée en fonction du nombre de processeurs et de leur puissance. L'autre partie de l'équation concerne le type de licence, qui dépend de la nature de l'application qui s'appuie sur la base de données. Les éditeurs fonctionnent tous de la même manière, avec un modèle de licence basé sur le fait que l'on peut, ou non, anticiper le nombre d'utilisateurs de l'application.

Dans le cas d'une application métier interne à l'entreprise, le nombre d'utilisateurs est généralement prévisible. On peut en conséquence opter pour un modèle de licence par poste. Avant, il fallait souvent choisir entre des licences établies en fonction du nombre d'utilisateurs simultanés (exemple : dans le cas ou l'entreprise comptait 100 utilisateurs, mais moins de 25 se connectaient simultanément, l'entreprise achetait 25 licences utilisateurs), ou le nombre d'utilisateurs déclarés (donc, en reprenant l'exemple précédent, il aurait fallu 100 licences). Oracle utilisait auparavant ce type de licence, mais a abandonné depuis quelques années, l'approche des « utilisateurs simultanés « pour ne conserver celle ce que l'entreprise appelle « utilisateurs nommés ».

Oracle a ainsi lancé une tendance, maintenant suivie par d'autres. La quasi-totalité des éditeurs utilisent des modèles de licence similaires, malgré des appellations différentes. Par exemple, avec SQL Server, il s'agira de CAL, ou Client Access Licences (Licences d'Accès Client). Encore une fois, IBM fait figure d'exception, puisque, même si elle se base sur le nombre d'utilisateurs autorisés, l'entreprise fait aussi intervenir son bon vieux PVU - en spécifiant un nombre minimum d'utilisateurs autorisés en fonction du PVU du serveur, ce qui signifie que si l'on a un matériel hyper-puissant mais seulement 100 utilisateurs, il faudra peut-être acheter davantage d'autorisations utilisateur pour atteindre le minimum prévu par la licence.

Les choses sont plus délicates avec les applications Web, puisque l'on ne peut pas prédire à coup sûr le nombre d'utilisateurs probable du serveur (ou, pour être plus précis, en convaincre l'éditeur). Il faudra donc opter pour une licence par processeur, qui permet un nombre infini d'utilisateurs mais est établie en fonction du nombre de processeurs (ou comme mentionné plus haut, la puissance totale des processeurs dans le cas de DB2), souvent ajusté par le biais d'un facteur artificiel qui s'applique aux processeurs multi-coeur (ce que pratique Oracle). Il arrive donc un moment où une licence par processeur devient plus économique que plusieurs dizaines de licences mono-utilisateur. Avec SQL Standard Edition, sur un serveur mono-processeur, on franchit ce cap autour de 35 utilisateurs.
Il faut également choisir l'édition du produit correspond bien au besoin. Sachant qu'une version mono-processeur de SQL Server Enterprise coûte un peu moins du double du prix de la version Standard par exemple. Il est important de vérifier également que l'édition requise existe dans le modèle de licence souhaité. Ainsi, Oracle 11g Personal Edition n'existe pas dans le modèle par processeur.

Divers autres facteurs sont à prendre en compte. Le coût de la maintenance, surtout si l'on est lié à un fournisseur donné, ne saurait être désolidarisé du coût total. Il faut aussi déterminer avec certitude quels changements pourront être effectués sur la plate-forme sous-jacente sans générer de coûts supplémentaires. Enfin, la montée de la virtualisation au sein des entreprises aura également un effet sur les licences logicielles - de nombreux éditeurs de logiciels de bases de données sont mieux armés pour faire face au monde physique qu'au monde virtuel.

Par exemple, il se pourrait qu'un contrat de licence force le client à désigner un processeur à l'intérieur d'une machine. Un utilisateur qui souhaite migrer un serveur virtuel vers un serveur physique devrait alors s'acquitter d'une licence pour chaque processeur de chaque serveur sur lequel la base de données tourne. Les éditeurs de logiciels de bases de données n'ont pas le monopole des difficultés dans la transition du physique au virtuel, mais toute entreprise qui cherche à virtualiser un serveur de bases de données devra d'abord poser la question des contrats de licence.