cPanel® Blog

Changing in 11.44 – Database Name Length Restriction

UPDATE – We have updated our plans for database prefixing and maximum username and database name lengths. For more information, read our latest post: Update to Recent Database Prefixing Post.

This year, we have worked to remove the restrictions on database name length. As of cPanel & WHM version 11.44, you will be able to create:

  • MySQL databases with names that are up to 64 characters long
  • PostgreSQL databases with names that are up to 63 characters long
  • PostgreSQL usernames that are up to 63 characters long

We will also disable database prefixing for new databases and remove the Database Prefixing option from WHM (Home >> SQL Services >> Disable Database Prefix).

New databases that you and your users create will not automatically include a username prefix. However, existing databases and databases that you transfer or restore will retain their username prefixes. You will still have the option to manually add a username prefix in a new database’s name.

Administrators and developers of plugins and other third-party software should plan accordingly.


I write things. Sometimes, I edit things. Then, I publish things.

28 responses to “Changing in 11.44 – Database Name Length Restriction”

  1. Alasdair Stewart says:

    This is a terrible idea, for all of the reasons discussed over at WHT
    (no point repeating them endlessly!): I really do hope
    you reconsider.

  2. Ryan Smith says:

    The option to keep database prefixing needs to remain. For shared hosts this just adds so much unnecessary complexity and inevitable conflicts. Please keep the option.

  3. Mark Wurkz says:

    This is a failure, it should be made just as an option and not by default.

  4. Karl Austin says:

    I can’t express how much of a bad idea this is. This is going to increase the support workload of hosts due to customers complaining that database names aren’t available – “But I’ve not created one called wordpress before”. That and it means taking a quick look at the MySQL processlist no longer informs who the troublesome user is without a further lookup. Bad bad bad idea cPanel, this is a step backwards.

    Extra steps needed to do any routine job are not good.

    You’d be far better off not changing stuff that works and fixing things that have been broken for several year, like maybe the poor multi-domain support?

  5. Kailash says:

    This is not a good move for server administrators and this will create lots of issue when server administrator plans to consolidate their 2-3 servers in one high performance server. There is a possibility of database name conflict when we consolidate 2-3 servers.

    Currently cPanel server consolidation is an easy and straight forward but after removing database prefix, I think it will not and it will be a pain for server administrators.

  6. Dean Walsh says:

    I would definitely prefer to have an option to leave the username prefix.

  7. Liroy van Hoewijk says:

    That is a major issue. With shared hosting platforms, you will have many users with the same database names.

    Can you imagine what an extreme pain it is that databases are constantly being skipped when they’re not unique on the system upon import? That’s a massive disaster.

    Considering the pains and major issues involved with dropping pre-fixing and the lack of any benefits, this really should not be added or should at the very least be made optional.

  8. Kenneth Power says:

    We don’t strip the prefix during transfer or restoration. If there is a naming conflict we skip the database (or username). What is presented in the original post would also not result in stripping existing prefixes.

  9. Liroy van Hoewijk says:

    Yeap, that’s what I wrote under the “is only reasonable…” part.
    The rest of the problems with migrations still exist. (non-prefix -> non-prefix imports)

  10. James Oakley says:

    I hadn’t read it that the prefixes would be dropped on importing to a server with prefixes disabled. If you import a database named user_dbname, it will be called user_dbname. The difference is that it’s now a coincidence that the first five characters of the database name are “user_”, and it’s not because of any formal prefix system.

  11. Liroy van Hoewijk says:

    “Transferring from a prefix-enabled server to a non-prefix-enabled server is simple.”

    It is? Might I ask how?
    Say you have four independent users that all have a database named “user_wordpress”. Now, you are going to import from the non-prefix-enabled server. Boom, you get four collisions. What will you do?
    Assign random names, add numbers?

    In all scenarios, the software depending on the database will cease working. When migrating a massive amount of accounts (either because moving/upgrading or because thats your daily job…) that means for each account you will have to define the new database name the software has to use.
    That’s an insane idea in my humble opinion to force upon shared hosting providers; especially because many software installations for open source projects, such as wordpress and Simple Machines Forum, make a suggestion for the db name or people simply use “wordpress” or “smf” or even “phpbb”.

    Transferring from a server with prefixes to one without is only reasonable when the prefix is kept on the database name. If the prefix is stripped from the database name: you are going to break software and in case of collisions it will again break the software.

    Even by moving from a non-prefix-enabled server to another non-prefix-enabled server you run in to exactly the same problem. You can’t have two databases named “wordpress”, so if you import a user that has that database while an existing user on that server already has that database name, what will the system do?
    If the database already exists: it will either not import it, or you will have to force renaming. In the latter case *at least* the database is imported, but you still have to do change configurations; and in the first scenario you have to import the database manually AND change configuration files.

    Actually… No matter what migration scenario I’m trying to think off here: it is always a clustercoitus of epic proportions.
    The prefix should stay, at the very very least as configurable option by the root administrator. Dropping the prefixes is simply a major problem, especially for large hosting providers that have thousands of accounts.
    Dropping the prefix adds absolutely no benefits at all. Zero. While having them there obviously seems to offer many benefits and keeps things much easier.

  12. James Oakley says:

    Exactly. So by disabling database prefixing, we lose something quite valuable. At the moment, a cPanel -> cPanel move is entirely automated and everything transfers – apart from a few very occasional edge cases. But with database prefixes disabled, that is no longer the case; database conflicts would become much more widespread, and there will then be manual work to do to finish the transfer.

  13. Kenneth Power says:

    Account transfer is rather complex with regard to database prefixing. Transferring from a prefix-enabled server to a non-prefix-enabled server is simple. Transferring in the other direction is not simple. When there are database conflicts we currently (to my knowledge) skip the database, storing it in a SLQ dump file within the home directory.

  14. Kenneth Power says:

    Thank you everyone for your honest (and passionate) feedback on what we felt to be a seemingly small matter internally. We are currently examining all the points you made.

  15. Eduardo Maio says:

    Please keep the option to maintain the prefixes. Plesk was like this and it was a nightmare, they have now enforced prefixes like CPanel does. There is a very good reason for that.

    It’s easier for a customer to name is database username_db instead of trying to create a new database db and seeing that is already exists.

  16. Rob says:

    This is an awful idea, even if it allows something like splitting an addon domain off of the main account. Rather than code a way to do that affecting only the addon account, Cpanel instead changes something so fundamental to the daily operation, likely breaking imports, and causing “name taken” issues over and over.
    Very much against this, and feel they should take the time to work it out for addons instead of making a big change like this that will cause a world of issues for providers and end users. The benefit does not outweigh the downside here, not by a long shot.

    Please don’t.

  17. Mark Birkedal Stjerslev Jakobs says:

    Someone realy need to point out the benefits of this change. I assume there is a good reason for doing it and it would realy like to hear it. Maybe it outweighs the drawbacks.

  18. Nick G says:

    This is by far the worst change I have seen in cPanel for years. Who had this idea?
    It will be almost impossible to track who owns a database. Also when migrate accounts/customers from other servers/companies what we will do if their database names are already used? Change their database names and ask them to reconfigure their scripts?
    The customers will leave and go elsewhere.
    Not to mention the tons of “database already exists” errors and customers opening tickets about this.
    A lot of frustration and problems, for what benefit? No benefits at all, no advantages, only new problems. Come on guys, drop this change, just tell us that it was a joke…

  19. James Oakley says:

    I, too, think that it is a really bad idea to make this mandatory. Fair enough to allow the option of discontinuing prefixes. Fair enough, even, to make “no prefixes” the default on new installations, with upgrades being given the choice when WHM is first loaded after the upgrade. But why is it necessary to force the change?

    First, to pick up what Kenneth Power said. Yes, there is a .yaml file that lists the ownership. But if I’m troubleshooting a load issue, running grep from the shell is several extra steps that are unnecessary.

    One problem that others have not yet mentioned is migrating accounts from another server (either from another host, or from another server internally). If the incoming account does not have a prefix, and they’ve picked something obvious and popular (like wordpress6), it’s highly likely (on a busy server) that there’ll already be a database with that name. How is the cpmove restore script going to fail gracefully? The database can’t be omitted from the account-restoration. But it has to get a new name. What new name? At the moment, moving an account with a full cpmove process leads to a new account that immediately works exactly as it did on the old server. But in this new scenario, the new database name would require configuration php files to be changed to supply the new name for the database. That relies on the client knowing what files need changing – so inbound migrations become a lot less clean and reliable.

    Please please please keep this optional. Again: Why force it?

  20. Randy says:

    This is a terrible idea on many levels, *especially* with no opt-out…c-mon cpanel, what are you thinking???

  21. Scott Neader says:

    I came here to give my two cents but Daniel, Electric and “Guests” have already made all the points I was going to make… this is a solution to a non-existent problem… will add time to various troubleshooting (mytop tool will be useless without the extra yaml lookup) … will make root phpMyAdmin less easy to use. Please keep the option to use prefixing… for those that don’t want to use it.. .fine by me… here, we prefer it. ALL THAT SAID… if this somehow will give us the ability to magically make an add-on domain its own account, then I’d trade prefixing for it.

  22. Guest says:

    I have to ask, what’s being fixed by making these changes? The DB name length change is nice – I like this, but removing the prefix and disabling the option to enforce it means having to manually add “[username]_” to each DB name, if you like how phpMyAdmin neatly sorts for you when you use this feature as root. Plus, since we never use the default cPanel username, we get an added bit of security by essentially forcing a long DB name and adding an unpredictable string to the front of the name. I’d really rather not see these just disappear, or if these changes are final, I’d love to know what problem is being solved by making this change. Please help a confused old man understand 🙂

  23. The ‘only’ way I view this as beneficial is if you are also planning on implementing a fully automatic way to split an add-on domain into its own cPanel account. Changing the DB naming structure would simplify that.

    One thing you fail to mention are the MySQL users, will they still be accountname_name or will you be removing that restriction on MySQL users as well?

    If not then why are you changing the DB names, if so then we run the same risk of X name taken for popular names.

    In the end this change depends on the end result as I’ve run across very few databases that need and/or use a name longer than 20-25 characters, 30 tops. By implementing this you add 3-10 seconds of work each and every time an administrator needs to identify the owner of a database, compared to the 1 second it takes to look @ either the MySQL directory structure and/or the mysql process list and simply say, well “bob_wordpress” belongs to the account bob, it is causing problems let’s look @ bob’s account.

    Now one will have to go, well crap, “wordpress12345” is causing problems.

    grep wordpress12345 /var/cpanel/databases/*.yaml

    Ok, wordpress12345 belongs to bob.

    In this day and age providing timely support to customers is a battle of seconds. This change adds to those numbers, and as described, provides minimal benefits as such.

    Food for thought 😉

  24. Kenneth Power says:

    Thank you for your input. You certainly raise some points to consider.

    I’d like to point out that we’ve stored ownership information in /var/cpanel/databases for a number of years now. If you want to see which databases are owned by user FOO, you can view /var/cpanel/databases/FOO.yaml. Both MySQL and PostgreSQL databases are stored in the yaml file. If you don’t know which user owns the database, you can use the grep utility:

    grep dbname /var/cpanel/databases/*.yaml

  25. electric says:

    >> New databases that you and your users create will not
    >> automatically include a username prefix.

    It would be nice to continue with the option to enforce the username_dbname prefix style that exists now. It is much simpler for our admins to see what databases belong to which account, and to find/remove orphan databases, etc…

    In 15 years of being in the hosting business, none of our customers have *ever* complained about being forced to have their database named “username_dbname”. So, cpanel developers, if you’re listening… this seems to be a case of fixing something that is not broken.

  26. Guest says:

    Will there be an option to keep and enforce this option? From a support and management perspective, being able to see who owns a database is easy now, but without the naming convention, wont we have to check grants to see where a databse belongs? And from a user perspective, having to name your database joomla77 because joomla1-76 was taken is a hassle.

Leave a Reply