Future proof Primary Key design in postgresql

Question

I've always used either auto_generated or Sequences in the past for my primary keys. With the current system I'm working on there is the possibility of having to eventually partition the data which has never been a requirement in the past. Knowing that I may need to partition the data in the future, is there any advantage of using UUIDs for PKs instead of the database's built-in sequences? If so, is there a design pattern that can safely generate relatively short keys (say 6 characters instead of the usual long one e6709870-5cbc-11df-a08a-0800200c9a66)? 36^6 keys per-table is more than sufficient for any table I could imagine.

I will be using the keys in URLs so conciseness is important.

Answer 1

There is no pattern to reduce a 128-Bit UUID to 6 chars, since information gets lost. Almost all databases implement a surrogate key strategy called incremental keys. Postgres and Informix have serials, MySql auto_increment, and Oracle offers sequence generators. In your case I think it would be safe to use integer IDs.

See this article: Choosing a Primary Key: Natural or Surrogate? for a discussion of availabe techniques

Answer 2

I'm not sure what type of partition are you planning (this?), but I don't see why to change the primary key design? Even if the old partitioned tables are "alive" (i.e., you might insert rows in any partitioned table), there is no problem in sharing the sequence among several tables.