I didn't read it but look after the strategies: sequences with serial IDs, for update skip locked

So, it's a matter of your requirements. If you need massive scale and throughput (> 100k messages/sec), Kafka will be hard to beat. But if you're not operating at that scale, Postgres is hard to beat.

So, it's a matter of your requirements. If you need massive scale and throughput (> 100k messages/sec), Kafka will be hard to beat. But if you're not operating at that scale, Postgres is hard to beat.

Here's the thing: 99% of companies don't need them. The top 1% have tens of millions of users and a large engineering team to match.

The fun thing about Postgres is there is already an extension for that: PostGIS, Full-text search, JSONB, TimescaleDB, pgvectorm, and many for AI

Each database add hidden costs: backup strategy, monitoring dashboards, seceurity patches, on-call runbooks, failover testing.

SLA math: Three systems at 99.9% uptime each = 99.7% combined

The permission system should handle folders and files.

Strategies:

1. (naive) read-time permission queries
2. A simple table (RBAC role based access control).

-- RBAC: Pre-computed permissions
-- access_type: 'owner' (full control), 'shared' (read only), 'path_only' (visible but no access)
CREATE TABLE permissions (
  user_id INTEGER NOT NULL,
  resource_id INTEGER NOT NULL,
  access_type TEXT NOT NULL,
  PRIMARY KEY (user_id, resource_id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (resource_id) REFERENCES resources(id)
);

3. Attribute-Based Access Control

This approach is very clear and composable. It works great for single-resource access checks: "can user X access resource Y?" It struggles when listing resources, as we would need to execute the policies for each resource and can't directly query the resources table with simple filters.

4. Zanzibar and ReBAC

Nice!

A case in favor of materialized views: it avoids caches; off-by-one error and so on.

There is currently a support for go, kotlin, python and typescript. It is very interesting, because it takes over one reason why ORMs are used (with migration handling and security).

The documentation is available at https://docs.sqlc.dev/en/latest/

and how to batch to optimize DELETEs

The perfect prisma alternative?

A (somewhat opinionated) list of SQL tips and tricks that I've picked up over the years in my job as a data analyst.

Okay

A query builder. It can be coupled to Prisma schema for better performance.

As much as I dig into it, I find raw SQL better (or with a SQL builder).

Le NoSQL est également plus adaptée pour le développement agile car les données ne sont pas structurées pendant les itérations.

Le SQL a réussi à traverser les âges car: il est simple, il est rapide et il est stable.

Les avantages de SQLite:

• facilité d'administration: tout le contenu peut être visualisé par lecture d'un fichier.
• facilité de déploiement: il est possible de pousser les BDD en production et de les migrer
• simplicité: sqlite est intégré avec tous les langages de programmation
• capacité: une BDD peut contenir plus d'un million de TB

Ses désavantages:

• requêtes concurrentes:
• les types de données limitées: NULL, INTEGER, REA L, TEXT, BLOB. Il n'y a pas de BOOL ni de dates.
• les données sont faiblement validées: "abcd" dans INTEGER o 20 charactères dans VARCHAR(5) passent.
• la sauvegarde des données est à faire soit même
• l'hébergement n'est pas possible avec tous les hébergeurs