Maybe double post but I could not find any answer here.

I saw couple of posts how to name my tables and I understood that (semi-officially) it should contain lower cases, should be underscored and singular (f.e. my_table)

My question arose when I had to do the following. I have an app where I have user, platform and user_info, where platform is what the user is working on (f.e. MAC, PC, LINUX). If I need to create junction table between user and platform, how do I name it in order the next person browsing the schema to understand that user and platform have a junction table named user_platform, but to not be confused when he sees the table user_info?


  • Choose one naming convention and stick to it! Use a search engine. Personally, I go with UPPER CASE for SQL and lower for other variables SELECT my_field FROM my_table; but that's me. See what suits you. p.s. welcome to the forum! :-)
    – Vérace
    Aug 18, 2019 at 1:55
  • Thank you very much for the response, but I cannot understand the answer. I am having difficulties naming junction tables and tables consisting of two nouns (user_info, order_details and so on)
    – Pentarex
    Aug 18, 2019 at 11:10

2 Answers 2


In case the reasoning behind lower-case names wasn't clear, here's why: Postgres automatically and invisibly folds names down. So, all of these names are the same:




They're all user_platform internally. Unless you put them in double-quotes:

"UserPlatform" is "UserPlatform". But to use this field or table, you would then need to put the name in double quotes everywhere you use it. It's a total pain. So, it's pretty standard to see names like


With that said, as long as you don't use the double-quotes, you can write the name


if you find it easier to read.

As far as the naming convention goes, yes, pick one, stick to it and document your rules. You get 64 characters to work with (by default), which I haven't found to be an issue, except sometimes for index names.

For linking tables, whatever you like is fine. Linking users and platforms?



whatever you prefer.

As far as the singular vs. plural argument, it's a matter of taste. Some people care. A lot. The gutters run red with the blood of the unrighteous! I say do whatever you like. I'm of the make-table-names-singular school, but mostly because it's a habit that I picked up long ago.

Ah, one thing about the double-quotes...I do use them. We ship Postgres data to a visualization/analytics program called Domo. For that, it's nicer to have column (attribute) names in MixedCase. For that, I create views with "MixedCase" column aliases so that the data exports with a "MixedCase" name. This is a slightly exotic scenario, but maybe you'll run into something similar one day. Normally, I'd change the tables client-side, but the views were the easier solution.

Bonus tip! If you haven't discovered it already, Postgres text fields are case-sensitive. If you don't like that, you can:

  • Write your queries to deal with the data case-blindly. Every. Single. Query.
  • Use the standard citext extension. (Case Insensitive Text.)
  • Wait for PG12 to ship with case-insensitive collations. (Haven't tried it out yet.)

Forgot to mention...Postgres has unusually good support for commenting on system elements, including tables:


Someone has to look for and read your comments, of course, but it's another place that you can provide context. Even if that context is nothing but a link to a wiki you maintain, etc.

  • Thank you, I will stick with link in between like user_link_platform. Makes more sense if you start reading. Or user_platform_xref.
    – Pentarex
    Aug 18, 2019 at 11:32

I'm thinking of using a naming convention of (noun) _ n _ (noun) for link tables. as in user_n_platform. Though I wish dash was allowed.
Then user-platform could link two tables
but user_platform would be its own table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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