PostgreSQL, multilingual DB, primary key type?

Question

PostgreSQL

The project I am developing (REST API) is divided into many modules. Each module stores data in its own database. The database of some modules may contain tables that refer to the data of other modules.
The project must support multiple languages. New languages ​​can be added at any time.
I chose the following structure for storing translatable entities:

CREATE TABLE languages
(
    id UUID NOT NULL PRIMARY KEY,
    code CHAR(2) NOT NULL,
    name TEXT NOT NULL
);
CREATE UNIQUE INDEX languages_code_uindex ON languages (code);

CREATE TABLE countries
(
    id UUID NOT NULL PRIMARY KEY,
    some_property INT
);

CREATE TABLE country_translations
(
    country_id UUID NOT NULL,
    language_id UUID NOT NULL,
    name TEXT NOT NULL,
    
    CONSTRAINT country_translations__pk PRIMARY KEY (language_id, country_id)
);

I have several questions:

1. I am using UUID as PK for all tables. Is it good?
   I chose UUID because in the REST API code I use the CQRS approach. Commands can't return any data => I can't return the Id of the created entry. Therefore, I generate a Guid and pass it to the command, after which I can return this Guid to the user.
   
2. Should I change the PK of the languages ​​table to char(2)? The code field will contain the language code (ISO-639-1). This code will be unique -> it can be made a PK for the Languages ​​table.
   

Answer 1

There are not so many countries as well as known languages ​​in this world. So even a full search through the table by the primary GUID key in modern databases takes a tiny fraction of the time. You should focus on more serious things.
As for using a GUID for all tables, there are pros and cons. Cons are associated with the space occupied and performance. Pluses with an easy search for elements in the system and the impossibility (very low probability) of collisions during various backups / deployments / database moves. All Microsoft's SharePoint works on these GUIDs...

Answer 2

UUID is needed in theory when you need super uniqueness and a fixed type of identifiers, regardless of the ID. Well, as protection against brute force.
Why put him in here? There are very few countries and languages, UUIDs will weigh more than the data taken together in the tables