Well, obviously UUDs should not be stored as a string but using a proper "uuid" data type (which also makes storing them much more efficient). Then the database will automatically reject the value with an error.
Couldn't actually find something similar for MySQL apart from using BINARY as the datatype, historical sources also refer to that though are (hopefully?) out of date: https://dev.mysql.com/blog-archive/storing-uuid-values-in-my...
An observation: seems like PostgreSQL is HN's darling (and maybe the industry's as a whole), i wonder why MariaDB doesn't get similar amounts of attention, apart from maybe not being as actively developed? Or maybe its relative simplicity or history works against it here?
I can obviously only speak for myself. But (in my opinion) Postgres simply offers the better overall package. I don't think there is a single "killer feature" that makes it better, but the sum of numerous things (JSON support, indexing, parallel query) that make it more efficient (and easier) to work with.
Note that the UUID type in MariaDB is not yet part of an officially released version. 10.7 is still in preview/alpha
[1] https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functi...
[2] https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functi...
So, if we think about it as using a int-128 or a string[~25], one of them takes more space than the other.
So, except for taking up more space, the question then becomes, are larger keys/indexes less efficient, I would say yes.
Other people can probably explain this better than me, but at least for me, it seems intuitive that going through and comparing entries in a list of small things is easier than doing it on a list of large things.
* Is there a SQL database with support for 128 bit integers?
Since you asked for "SQL database" and not really "OLTP database": ClickHouse natively supports UUID and 128-bit numeric datatypes. I think by now it also supports 256-bit.
[1]: https://clickhouse.com/docs/en/sql-reference/data-types/int-...