Animé par : Horacio GONZALEZ
Avec la participation de :
- Mathieu SANTOSTEFANO
- Sébastien BRUNAT
- Julien DURILLON

Episode enregistré le 26 septembre 2025

Montage : Yann BRESSON @ Smartmedias

Chapitrage et Liens

00:00:16 - Présentation des invités

00:02:20 - Symfony UX, modern web app without writing much JS 

• https://ux.symfony.com/
• Symfony AssetMapper, avoid nodejs to build your frontend app  (permet de se passer du builder nodejs) https://symfony.com/doc/current/frontend.html#assetmapper

00:08:51 - Symfony AI, tool set of PHP components to bring AI capabilities to applications, with native Symfony integration 

• https://symfony.com/blog/kicking-off-the-symfony-ai-initiative

00:14:08 - Postgresql 18 released - https://lwn.net/Articles/1039483/ https://www.postgresql.org/about/news/postgresql-18-released-3142/

• Async IO pour l’accès disque (par exemple avec io_uring)
• Meilleures perfs sur les requêtes (notamment gestion d’index et query planning)
• Support d’OAuth et depréciation du md5 hashed password
• `uuidv7()`

00:22:45 - Java 25 released 

• https://mail.openjdk.org/pipermail/announce/2025-September/000360.html 
• https://jdk.java.net/25/release-notes 

00:29:10 - PHP 8.5 RC1 https://www.php.net/archive/2025.php#2025-09-25-3

• Version finale attendue en novembre
• Quoi de neuf dans PHP 8.5 https://sensiolabs.com/blog/2025/new-in-php-85
  • Ajout du Pipe Operator
  • Nouvelles fonctions de manipulation d’arrays
  • Getter d’Error et Exception handlers

00:35:55 - Calendrier release Symfony 

• https://symfony.com/releases

00:48:50 - One Token to rule them all - obtaining Global Admin in every Entra ID tenant via Actor tokens 

• https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/ 
• Entra ID = Azure Active Directory

00:54:40 - REMPAR25 exercice national de crise cyber 

• https://cyber.gouv.fr/actualites/rempar25-un-exercice-de-crise-cyber-dune-ampleur-inedite

00:56:00 - Outil de l’épisode : Tailspin, un pager qui met de la couleur dans tes logs 

• https://github.com/bensadeh/tailspin

01:00:10 - Musique de fin 1 – Le dernier jour du disco, Juliette Armanet https://www.youtube.com/watch?v=hTHmZYC7Zws

• Musique de fin 2 - Archive - Lights https://www.youtube.com/watch?v=yLuOzNeHw5I ⚠️ 18min
• Musique de fin 3 - https://www.youtube.com/watch?v=hYiWXWywiPM&pp=ygUWZW5jb3JlIHVuIG1hdGluIGNlcGhheg%3D%3D 

When I started working at Clever Cloud, I spent some time messing around with the platform and its tooling. This blog post will present you how I managed to:

• create a simple Scala/Akka HTTP template application with PostgreSQL persistence
• link the application to a managed PostgreSQL
• deploy it
• try it!

Create a Scala/Akka HTTP template 🔨

Get the sources

Clone the project generated from Akka Github quick start template.

This service provides the ability to manage a simple in-memory user registry exposing 4 routes:

• List all users
• Get a specific user
• Create a user
• Delete a user

A thorough description of available the cURL commands may be found here.

Add extra features

A few functionalities have been added on top of the original example:

• store the registry into a PostgreSQL database (instead of in memory)
• read database parameters from environment variables
• add a hardcoded basic authentication

All parameters may be specified in the application.conf file:

• basic auth
• database parameters

Parameters are fetched from environment variables, or the specified default value if none is found

app {
  basic-auth {
    user = "foo"
    user = ${?BASIC_AUTH_USER}
    password = "bar"
    password = ${?BASIC_AUTH_PASSWORD}
  }
  routes {
    # If ask takes more time than this to complete the request is failed
    ask-timeout = 5s
  }

  db {
    host = "localhost"
    host = ${?POSTGRESQL_ADDON_HOST}
    port = "5432"
    port = ${?POSTGRESQL_ADDON_PORT}
    database = "postgres"
    database = ${?POSTGRESQL_ADDON_DB}
    user = "login"
    user = ${?POSTGRESQL_ADDON_USER}
    pass = "pass"
    pass = ${?POSTGRESQL_ADDON_PASSWORD}
  }
}

Run the application using Clever Cloud CLI 🚀

Create a Clever Cloud application

clever create --type sbt myakka --region par --org testorg

This command creates a new application

• of type sbt for Scala
• named myakka
• in Paris region
• inside my test organisation testorg

Enable a dedicated build instance for faster build (optional pro tip)

By default a newly created application will run an XS instance which are quite small for building Scala applications fast. One way to build faster is to use a dedicated build Instance: In the Clever Cloud console, got to your application -> options, and check the box [] Enable dedicated build instance This way you can keep your XS instance for running the application, but you can choose an XL for the build time. Or with the command line tool:

clever scale -a myakka --build-flavor XL

Create a PostgreSQL database

clever addon -l myakka create postgresql-addon myakkadb

This command orders a PostgreSQL add-on instance and link it to myakka, injecting the right environment variables into the application instance to contact the database.

Database creation and migration is performed using flywaydb tool. Those script may be found in the migration/db directory of the application resources.

Migration will be automatically called once you specify the proper build hook in the environment variables

CC_POST_BUILD_HOOK with value sbt flywayMigrate

clever env -a myakka set CC_POST_BUILD_HOOK "sbt flywayMigrate"

Configure basic auth environment variables

Basic authentication login and password can be specified as environment variables using the clever env command. If none is found, basic authentication will default to application.conf file values

clever env -a myakka set BASIC_AUTH_USER <YOUR_AUTH_USER>
clever env -a myakka set BASIC_AUTH_PASSWORD <YOUR_AUTH_PASSWORD>

Link your local repo with your Clever Cloud application instance

Retrieve your application id with

clever applications

Then link the local repository to the application (creating a .clever.json file)

clever link app_<UUID>

Deploy

You are now ready to deploy and run your code, just run

clever deploy

You are now able to follow the deployment process until it completes successfully

Your application is running now!

Try it

It's time to experiment with it using curl or your favorite GUI

Add a user

Adapt this command in order to insert a new user into the registry:

curl --request POST \
  --url https://app-<UUID>.cleverapps.io/users \
  --header 'Content-type: application/json' \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>' \
  --data '{
  "name": "Serge",
  "age": 42,
  "countryOfResidence": "Greenland"
}'

{
	"description": "User Serge created."
}

Get all users

Check that the user has been properly created, by getting the list of users:

curl --request GET \
  --url https://app-<UUID>.cleverapps.io/users \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>'

{"users":[{"age":42,"countryOfResidence":"Greenland","name":"Serge"}]}

It works, Success! 🎉

Dans cet incroyable épisode, il est question : de la CNIL et de Google Analytics, de la faille #log4shell, d'authentification, de la version 100 de Chrome et Firefox, d'un nouveau container pour les requêtes, d'un incident poilu sur PostgreSQL, de migration de métadata, d'exécution de code arbitraire et d'extension de cockpit JSON… pour finir, comme il se doit en musique.

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Timecodes & liens :

00:00:00 Introduction et présentation de l’invité
https://github.com/gravitee-io/

00:00:00 La CNIL met en demeure un gestionnaire de sites français pour son usage de Google Analytics
https://www.cnil.fr/fr/utilisation-de-google-analytics-et-transferts-de-donnees-vers-les-etats-unis-la-cnil-met-en-demeure
https://www.linkedin.com/feed/update/urn:li:activity:6897522101679390720/
https://matomo.org/matomo-cloud/

00:12:45 : LCC 272 - Interview sur Log4Shell avec this
https://lescastcodeurs.com/2022/02/12/lcc-272-interview-sur-log4shell-avec-this/
https://snyk.io/
https://logback.qos.ch/news.html

00:19:10 Le chien qui se mord la queue… de la gestion des authentications / autorizations
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/04/
Next-generation protocol : GNAP https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol

00:27:00 Version 100 in Chrome and Firefox
https://hacks.mozilla.org/2022/02/version-100-in-chrome-and-firefox/
https://wicg.github.io/ua-client-hints/
Retrospective and Technical Details on the recent Firefox Outage
https://hacks.mozilla.org/2022/02/retrospective-and-technical-details-on-the-recent-firefox-outage/

00:35:20 A New Container Query Polyfill That Just Works
https://css-tricks.com/a-new-container-query-polyfill-that-just-works/
https://caniuse.com/css-container-queries

00:39:50 A Hairy PostgreSQL Incident
https://ardentperf.com/2022/02/10/a-hairy-postgresql-incident/

00:43:45 Migrating Snowflake’s Metadata with No Downtime
https://medium.com/snowflake/migrating-snowflakes-metadata-with-no-downtime-ca90604b677c

00:50:15 ldd arbitrary code execution
https://catonmat.net/ldd-arbitrary-code-execution
https://github.com/gentoo/pax-utils

00:55:45 RFC sur l’ajout du support de JSON dans cURL
https://github.com/curl/curl/discussions/8312
https://daniel.haxx.se/blog/2022/02/02/curl-dash-dash-json/

00:58:15 jless — a command-line JSON viewer
https://pauljuliusmartinez.github.io/

01:01:00 Choix musical de David Brassely : Alabama Shakes - Don't Wanna Fight
https://www.youtube.com/watch?v=nin-fiNz50M

What is Pgpool-II?

No more connection refused

• Accessed on a Unix socket: faster than a TCP socket. Gotta chase those nanoseconds.
• Connection reuse: Pgpool saves connections and reuses them when similar ones come in (same user, same database…).
• Managing exceeding connections: Normally, PostgreSQL takes only so many concurrent connections, and discards any additional ones, which compromises the app. Pgpool-II, instead, queues the excess connections for later. No more connection refused.

What do I have to do?

$host = getenv("POSTGRESQL_ADDON_HOST");

$host = getenv("CC_PGPOOL_SOCKET_PATH");

Load balancing: let's go big

What is Ratpack?

• Ratpack is a set of Java libraries for building modern HTTP applications.
• It provides just enough for writing practical, high performance, apps.
• It is built on Java 8, Netty and reactive principles.

Setup

• Create the application: clever create --type gradle ratpackTest --region par
• Link the add-on: clever service link-addon ratpackPG

db:
  username: ${POSTGRESQL_ADDON_USER}
  password: ${POSTGRESQL_ADDON_PASSWORD}
  database: ${POSTGRESQL_ADDON_DB}
  poolSize: 4
  hostname: ${POSTGRESQL_ADDON_HOST}
  port: ${POSTGRESQL_ADDON_PORT}

clever env set RATPACK_PORT 8080
clever env set db_database \${POSTGRESQL_ADDON_DB}
clever env set db_hostname \${POSTGRESQL_ADDON_HOST}
clever env set db_password \${POSTGRESQL_ADDON_PASSWORD}
clever env set db_port \${POSTGRESQL_ADDON_PORT}
clever env set db_username \${POSTGRESQL_ADDON_USER}
clever env set db_poolSize 4

public Observable<Product> getProducts() {
  return pool.queryRows("select * from product").map(row -> {
    Long id = row.getLong("product_id");
    String name = row.getString("name");
    String description = row.getString("description");
    Boolean available = row.getBoolean("is_available");
    BigDecimal price = row.getBigDecimal("price");
    return new Product(id, name, description, available, price);
  }).doOnError(Throwable::printStackTrace);
}

CREATE TABLE public.product (
   product_id   bigint,
   name   text,
   description   text,
   is_available   boolean,
   price   double precision
);
INSERT INTO product(product_id, name, description, is_available, price)
       VALUES (1, 'product name','product description', true, 20.00);

touch data.sql
echo "CREATE TABLE public.product (product_id   bigint,   name   text,   description   text,   is_available   boolean,   price   double precision); INSERT INTO product(product_id, name, description, is_available, price) VALUES (1, 'product name','product description', true, 20.00);" > data.sql

Deploy

{
  "deploy": {
    "goal": "run"
  }
}

git add clevercloud/gradle.json src/main/resources/application.yml
git commit -m"add clever cloud specifics"

What is Ruby on Rails?

Ruby on Rails, or simply Rails, is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller framework, providing default structures for a database, a web service, and web pages.

Setup

• Start by cloning the sources, here I am checking out the latest stable branch: git clone https://github.com/edavis10/redmine/ --branch 3.4-stable
• Create the database you want to use, in my case Postgres: clever addon create postgresql-addon --plan dev --region eu redminePG
• Create a FS Bucket: clever addon create fs-bucket --plan s --region eu redmineFS
• Create the Ruby application on Clever Cloud: clever create --type ruby redmine --region par
• Link the Postgres add-on to the application: clever service link-addon redminePG
• Link the FS Bucket add-on to the application: clever service link-addon redmineFS

production:
  adapter: postgresql
  database: <%= ENV["POSTGRESQL_ADDON_DB"] %>
  host: <%= ENV["POSTGRESQL_ADDON_HOST"] %>
  username: <%= ENV["POSTGRESQL_ADDON_USER"] %>
  port: <%= ENV["POSTGRESQL_ADDON_PORT"] %>
  password: <%= ENV["POSTGRESQL_ADDON_PASSWORD"] %>
  encoding: utf8

• Define a new global secret in config/secrets.yml: touch config/secrets.yml

  production:
    secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
  

• Define all the other configuration variables under config/configuration.yml: touch config/configuration.yml

  production:
    attachments_storage_path: <%= ENV["APP_HOME"] %><%= ENV["ATTACHMENTS_STORAGE_PATH"] %>
  

• Set the Ruby version: clever env set RUBY_VERSION 2.3.1
• Setup the Rails environment to use the production configuration: clever env set RAILS_ENV production
• Use en as language: clever env set REDMINE_LANG en
• Use a newly generated secret: clever env set SECRET_KEY_BASE `./bin/rake secret`
• Setup where to write files: clever env set ATTACHMENTS_STORAGE_PATH /data/attachments
• Define where to mount our FS Bucket:clever env set CC_FS_BUCKET /data:`clever env | awk -F = '/BUCKET_HOST/ { print $2}'`

[ -d tmp ] || mkdir tmp
[ -d tmp/pdf ] || mkdir tmp/pdf
[ -d data/plugin_assets ] || mkdir data/plugin_assets
[ -d tmp/pdf ] || mkdir tmp/pdf
[ -d data/attachments ] || mkdir data/attachments

Deploy

{
  "deploy" : {
    "rakegoals": ["db:migrate"],
    "sidekiq": true
  }
}

git checkout -b clever/deploy
git add Gemfile.lock clevercloud/initDirectories.sh clevercloud/ruby.json config/configuration.yml config/database.yml config/secrets.yml
git commit -m"add clever specifics"
clever deploy

[ldoguin@caolila redmine]$ clever ssh
Opening an ssh shell.
Warning: Permanently added '[195.154.154.198]:40707' (ED25519) to the list of known hosts.
bas@76afae97-762c-43ee-b861-d5db873b553d ~ $ cd app_58f97386-2ec5-48b6-a774-31d64241f692/
bas@76afae97-762c-43ee-b861-d5db873b553d ~/app_58f97386-2ec5-48b6-a774-31d64241f692 $ RAILS_ENV=production bundle exec rake redmine:load_default_data
Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] 
====================================
Default configuration data loaded.
bas@76afae97-762c-43ee-b861-d5db873b553d ~/app_58f97386-2ec5-48b6-a774-31d64241f692 $ 

Setup and Deploy a Preproduction Redmine

clever addon create postgresql-addon --plan s --region eu redminePG
clever addon create fs-bucket --plan s --region eu staging-redmineFS
clever create --type ruby staging-redmine --region par
clever service --alias staging-redmine link-addon staging-redminePG
clever service --alias staging-redmine link-addon staging-redmineFS
clever env --alias staging-redmine set RUBY_VERSION 2.3.1
clever env --alias staging-redmine set RAILS_ENV production
clever env --alias staging-redmine set REDMINE_LANG en
clever env --alias staging-redmine set SECRET_KEY_BASE `./bin/rake secret`
clever env --alias staging-redmine set ATTACHMENTS_STORAGE_PATH /data/attachments
clever env --alias staging-redmine set CC_FS_BUCKET /data:`clever env --alias staging-redmine  | awk  -F = '/BUCKET_HOST/ { print $2}'`
clever env --alias staging-redmine set CC_PRE_RUN_HOOK ./clevercloud/initDirectories.sh
clever deploy --alias staging-redmine

What is Django?

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of Web development, so you can focus on writing your app without needing to reinvent the wheel. It’s free and open source.

Setup

• Clone the project: git clone https://gitHub.com/taigaio/taiga-back.git
• Get in the project: cd taiga-back
• Create our Postgres add-on: clever addon create postgresql-addon --plan dev --region eu taigaPG
• Create our FS Bucket add-on: clever addon create fs-bucket --plan s --region eu taigaFS
• Create our application: clever create --type python taiga --region par
• Link our Postgres add-on: clever service link-addon taigaPG
• Link our FS Bucket add-on: clever service link-addon taigaFS
• Define the python version to use: clever env set PYTHON_VERSION 3
• Define where to mount our FS Bucket: clever env set CC_FS_BUCKET /data:`clever env | awk -F = '/BUCKET_HOST/ { print $2}'`
• Define the secret used by the app: clever env set SECRET theveryultratopsecretkey
• Define the frontend domain name: clever env set FRONT_DOMAIN taigald.cleverapps.io"
• Define the HTTP schema: clever env set HTTP_SCHEMA https"
• Define where to store media: clever env set STORAGE_MEDIA /data/media"
• Define where to store static files: clever env set STORAGE_STATIC /data/static"

from .common import *
import os

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.getenv("POSTGRESQL_ADDON_DB"),
        'USER': os.getenv("POSTGRESQL_ADDON_USER"),
        'PASSWORD': os.getenv("POSTGRESQL_ADDON_PASSWORD"),
        'HOST': os.getenv("POSTGRESQL_ADDON_HOST"),
        'PORT': os.getenv("POSTGRESQL_ADDON_PORT"),
    }
}

MEDIA_ROOT = os.path.join(BASE_DIR, os.getenv("STORAGE_MEDIA"))
STATIC_ROOT = os.path.join(BASE_DIR, os.getenv("STORAGE_STATIC"))
MEDIA_URL = ""https://" +  os.getenv("FRONT_DOMAIN") + os.getenv("STORAGE_MEDIA")
STATIC_URL = "https://" +  os.getenv("FRONT_DOMAIN") + os.getenv("STORAGE_STATIC")
SITES["front"]["scheme"] = os.getenv("HTTP_SCHEMA")
SITES["front"]["domain"] = os.getenv("FRONT_DOMAIN")

SECRET_KEY = os.getenv("SECRET")

DEBUG = False
PUBLIC_REGISTER_ENABLED = True

• Create the hook script: mkdir clevercloud; touch clevercloud/buildDirectories.sh && chmod +x ./clevercloud/buildDirectories.sh
• Use the following code for the shell script:

  [ -d $STORAGE_STATIC ] || mkdir -p $STORAGE_STATIC
  [ -d $STORAGE_MEDIA ] || mkdir -p $STORAGE_MEDIA
  

• Define the hook: clever env set CC_PRE_BUILD_HOOK ./clevercloud/buildDirectories.sh

• Clone the project: git clone https://gitHub.com/taigaio/taiga-front-dist.git
• Get in the project: cd taiga-back
• Get the latest stable version: git checkout stable
• Copy the default configuration file: cp dist/conf.example.json dist/conf.json
• Change the backend URL: sed -i 's,http://localhost:8000/api/v1/,http://taigabackld.cleverapps.io/api/v1/,g' dist/conf.json
• Create the static website: clever create --type static-apache taiga-front
• Link this website to our FS Bucket addon: clever service link-addon taigaFS
• Setup its mount point: clever env set CC_FS_BUCKET /dist/data:`clever env | awk -F = '/BUCKET_HOST/ { print $2}'`
• Add a domain name: clever domain add taigald.cleverapps.io

{
  "deploy": {
    "webroot": "/dist"
  }
}

Deploy

• Define the Python module we want to start: clever env set CC_PYTHON_MODULE taiga.wsgi
• Define the Python backend to use: clever env set PYTHON_BACKEND gunicorn
• Deploy the app: clever deploy

python manage.py migrate --noinput
python manage.py loaddata initial_user
python manage.py loaddata initial_project_templates
python manage.py compilemessages
python manage.py collectstatic --noinput
python manage.py sample_data

As big users of PostgreSQL, we had the opportunity of re-thinking the idioms common in the world of relational DBs.

Today, I'll talk about why we stopped using serial integers for our primary keys, and why we're now extensively using Universally Unique IDs (or UUIDs) almost everywhere.

TL;DR

Use UUIDs as primary keys. They can be freely exposed without disclosing sensitive information, they are not predictable and they are performant.

Primary keys, technical keys and semantic keys

A relational database is a graph where nodes are called entities and edges relations. To be able to express a relation between entities, we need to be able to uniquely refer to any entity: that's the role of a primary key.

The role of a primary key is to provide a stable, indexable reference to an entity. You have two ways to construct your primary key: either as a semantic key, or as a technical key.

A semantic primary key is extracted from the entities attributes (ie you use one or several fields of your entity as its primary key).

A technical primary key is completely unrelated to the fields of its entity. It's constructed when the entity is inserted in the DB.

Ideally, semantic keys would be better, as it allows for a very simple way to understand and compare entities. But relational DBs are built upon a fundamentally mutable model. The current state of the world is stored in the database, and entities are subject to mutation. Relational DBs are very good at storing a relatively small amount of data, and are not well suited for immutable databases.

That's why to be able to have stable primary keys, we commonly resort to serial IDs. Serial IDs are a technical key, as they're not related to the actual contents of its entity.

To be fair, you can configure your foreign key to have ON UPDATE CASCADE to have primary key updates automatically propagated everywhere within the database, but it doesn't solve the problem if you've exposed primary key values outside the DB.

What's a serial ID?

Basically, a serial id is a number that increases everytime you insert a row. The database does the bookkeeping for you, so it's transparent for the developer.

create table entity(
  entity_id serial primary key,
  attribute text not null
);

We can then insert values in the table; postgres will handle the entity_id field.

> insert into entity (attribute) values ('ohai');
INSERT 0 1

> select * from entity;
    entity_id | attribute 
-----------+-----------
            1 | ohai
(1 row)

The row has been inserted, and the entity has an automatically attributed id. In postgresql, serial is implemented through a sequence, which acts a bit like a counter. We can inspect its current state:

> select currval('entity_entity_id_seq'::regclass);
currval 
---------
        1
(1 row)

OK, so we have a perfectly good primary key for our entities. What's the problem?

Why serial IDs can be a problem

Information disclosure

The current value corresponds to the last value used as a primary key. Since the sequence starts at 1 and is incremented 1 by 1, currval roughly corresponds in our case to the number of rows in the table (not exactly, because of deletions).

So, if you want to count the number of rows in a given table, all you have to do is to have the system generate a new entity and inspect its ID.

So, do users have access to primary keys? The answer is often yes: primary keys are very often exposed to the user, most often in URLs, as we want URLs to be stable (see cool URIs don't change).

Let's say you're a company operating a SaaS, all it takes to know your user count is to create an account. A number of social networks boasting impressive user bases were pwn3d this way. Just by creating an account and looking at a link.

Entity enumerations

An even bigger problem is that it's very easy to enumerate the entities in any given table. You start from 1, and you keep on incrementing the value. It becomes very easy to scrape all your entities. It leads to spamming (just don't start from 1, as you don't want to spam the admin team ;-) ), or worse. If you have light access control, only based on the knowledge of a given URL, then anybody can display private information.

Non uniqueness across tables

Since each table has its own sequence, an identical value will be found as the primary key of different entities. Now imagine you make a tab-completed typo when deleting a row. Yeah, you've just deleted an arbitrary row somewhere in your DB. Let's hope you don't have too many ON DELETE CASCADE configured.

Workarounds

You can configure your sequence to start at an arbitrary point, have an increment bigger than one, or even share the sequence between tables. In any case, you're still disclosing information about your growth, and you'll just reach integer overflow quicker. Not really a perfect solution.

A word on UUIDs

You may already have seen stuff like c0b656b1-7351-4dc2-84c8-62a2afb41e66 somewhere. This is a UUID (or Universally Unique IDentifier).

Which is nice. UUIDs are guaranteed to be Universally Unique, which makes them good candidates for primary keys (and neatly solve the issue of having primary keys non unique across tables).

More precisely, UUIDs are 128 bits values, with textual representation in hex digits. It bears repeating, because many people think that UUIDs are stored as text.

UUIDs are 128 bit values

There are different versions of UUIDs, based on how they're created. Within the 128 bits, 4 are used to encode the version. The kind we're interested in is UUIDv4, which is based on randomness.

UUIDv4 are perfectly well indexed by PostgreSQL

UUIDv4 values are random

UUIDv4 values being random, you don't have a guaranteed uniqueness. However, the probability of a collision is rather small (see Random UUID probability of duplicates).

Also, keep in mind that in the extremely unlikely case (you're more likely to get hit by a meteorite) of colliding UUIDs, it will be caught by the DB thanks to the primary key constraint.

UUIDv4 adds two reserved bits to the already used ones, so we're left with 122 bits of information.

λ> 2 ^ 122
5316911983139663491615228241121378304

This should be enough for your needs.

The fact that UUIDv4 values are random gives us interesting properties:

• you can't enumerate values
• you don't know how many values are present in each table
• you don't have to talk to the database to construct a value

The two first properties are nice, scroll up if you don't remember why. The third one deserves some extra explanations.

Sequences are mutable state, you need atomicity on get-and-increment, to preserve uniqueness. So everytime you need to insert an entity, you need the DB to give you its primary key. The entities in your code are incomplete until you talk to the DB. Since a sequential key is technical, not semantic, this can usually be handled by your ORM (or data mapper, ORMs are bad, m'kay?). When inserting several related entities, this can cause additional problems, because you're not only lacking the primary keys, but also the foreign keys too, which are semantic, not just technical.

The UUIDv4 generation algorithm is well documented and available virtually anywhere, so you can generate whole entities without ever talking to the database. This makes the code simpler and clearer as you don't have to handle partially-created entities, and you can test your entity-generation code without having to talk to a giant blob of mutable state over the network.

Also, serial is a 32 bit integer. You'll reach overflow at some point. Debugging it and migrating a production database to 64 bit integers is an interesting experience, but maybe you can take my word for it and avoid it altogether. With UUIDs it's a problem you just don't have.

Also, if you're brave enough to run a SQL database in a multi-master setup (please, please, please, DON'T), then you're relieved from the shenanigans of having conflict avoiding sequence generation. But please don't run SQL databases in multi-master setups. I have done that: one star, would not recommend.

UUIDs in PostgreSQL

PostgreSQL supports UUIDs, through the type uuid.

> select '697dffc9-8ba5-410c-b677-227475a73530'::uuid;
uuid                 
--------------------------------------
    697dffc9-8ba5-410c-b677-227475a73530
(1 row)

By default PostgreSQL doesn't have the ability to generate UUIDv4 values. You need the uuid-ossp extension for that. From 9.4, UUIDv4 generation is also provided by the pgcrypto extension.

CREATE EXTENSION "uuid-ossp";
-- or CREATE EXTENSION "pgcrypto";
create table entity(
  entity_id uuid primary key default uuid_generate_v4(),
  -- or entity_id uuid primary key default gen_random_uuid(),
  attribute text not null
);

> insert into entity (attribute) values ('toto');
INSERT 0 1
> table entity;
                entity_id               | attribute 
--------------------------------------+-----------
    b2a3d43b-5b81-4127-be29-d849de607d78 | toto
(1 row)

You can use UUIDs without the uuid-ossp extension, but you will have to provide UUIDs when inserting entities (which is a good thing to do anyway).

When UUIDs are not what you need

If you don't have mutable state, then you don't need a technical primary key, and you can use a semantic key.

If you have strong storage constraints, UUIDs can cause a problem, since they use 2 to 4 times as many space as a serial or big serial. So if you have strong size constraints and if you don't expose the primary keys, then UUIDs may be overkill. Also, UUIDs being random, you lose locality, and your index ends up scattered. This causes a definite performance hit when confronted to high insert rates. Also, this creates extra disk use.

In my experience, UUIDs are a safe default. You can question it when you have strong performance constraints and a safe environment.

How to generate UUIDs in $LANGUAGE

Java, Scala

It's in the standard library.

java.util.UUID.randomUUID

Node.js

npm install uuid

var uuid = require("uuid");

uuid.v4();

PHP

Install ramsey/uuid from composer.

$uuid4 = Uuid::uuid4();

Haskell

Install uuid from hackage

uuid :: IO UUID
uuid = nextRandom

Since the beginning, anyone can use mutual Clever Cloud databases for free because it was in beta.
Actually, this test period is over and databases will be charged from July 1st 2013.

In order to fit high performance needs, we will launch dedicated databases soon

The finesse pricing is daily. It means that once you create a database, you are charged for one day usage, and so on.
For example, a S database will cost 0,23 €/day.

The pricing plans for PostgreSQL and MySQL will be the following:

MySQL pricing plans

	S	M	L
Connexions	15	30	40
Size	1 Go	5 Go	10 Go
Price	7 €/month (0,23 €/day)	35 €/month (1,17 €/day)	70 €/month (2,33 €/day)

PostgreSQL pricing plans

	S	M	L
Connexions	15	30	40
Size	1 Go	5 Go	10 Go
Price	7 €/month (0,23 €/day)	35 €/month (1,17 €/day)	70 €/month (2,33 €/day)

You will be able to configure the number of Scalers dedicated to your database as you can do with apps.

These databases will be more powerful, larger and more scalable than the mutualised databases.

Version française

Depuis le début, tout le monde pouvait utiliser gratuitement les bases de données mutuelles sur Clever Cloud puisqu’elles étaient en beta. Désormais, cette phase de test s’achève et l’utilisation des bases de données sera facturée à partir du 1er juillet 2013.

Les tarifs pour une PostgreSQL et une MySQL seront les suivants:

Tarification PostgreSQL

	S	M	L
Connexions	15	30	40
Taille	1 Go	5 Go	10 Go
Prix (HT)	7 €/mois (0,23 €/jour)	35 €/mois (1,17 €/jour)	70 €/mois (2,33 €/jour)

Tarification MySQL

	S	M	L
Connexions	15	30	40
Taille	1 Go	5 Go	10 Go
Prix (HT)	7 €/mois (0,23 €/jour)	35 €/mois (1,17 €/jour)	70 €/mois (2,33 €/jour)

L’ajustement du pricing est quotidien. Cela signifie qu’une fois que vous avez créé la base de données, vous serez facturé pour une journée d’usage, et ainsi de suite.

À titre d’exemple, une base de données de taille S coûtera 0,23 €/jour.

Pour répondre aux besoins de haute performance, nous lancerons bientôt des bases de données dédiées

Il sera possible de configurer le nombre de Scalers dédiés à la base de données, comme il est déjà possible de le faire avec les applications.

Ces bases de données seront plus puissantes, plus scalables et auront plus de capacité de stockage que les bases de données mutualisées.

French version below

We have updated PostgrSQL following the security flaw detected in versions 9 and 8. To be more exact, there were 3 flaws, with one more important: CVE-2013-1899. This one could lead to corrupt postgres datas. Two smaller ones came after it: CVE-2013-1900 and CVE-2013-1901.

These flaws affected the 4 last versions: 9.2, 9.1, 9.0 and 8.4 (8.3 is no longer supported by Clever Cloud).

Owing the critical nature of the issue, an announce was done last week indicating that public repositories will be closed until the relase of april, 4th.

All our clusters has been updated since, leading to a shut down of a few seconds.

Moreover, we also took advantages of this opportunity to manage the distribution of 3 of 4 new versions of Exherbo.

The Clever Cloud's support remains at your disposal for any questions: mailto:support@clever-cloud.com.

Version française

Nous avons effectué la mise à jour de PostgreSQL suite à la faille de sécurité détectée dans les versions 9 et 8.

Plus exactement, il y a eu 3 failles dont une très importante : la CVE-2013-1899. Celle-ci pouvait amener à la corruption des données postgres. Deux autres plus petites lui ont succédé: CVE-2013-1900 et CVE-2013-1901

Ces failles touchaient les 4 dernières branches: 9.2, 9.1, 9.0 et 8.4 (8.3 n'étant pas supportée par Clever Cloud).

Compte tenu de la nature critique de l'incident, une annonce a été faite la semaine dernière indiquant que les dépôts publics seraient fermés en attendant la release du 4 avril.

Tous nos clusters ont depuis été mis à jour, entrainant une coupure de quelques secondes.

De plus, nous en avons profité pour gérer la distribution de 3 des 4 nouvelles versions Exherbo.

Le support Clever Cloud reste à votre disposition si vous avez des questions : mailto:support@clever-cloud.com.