Un prompt peut-il remplacer SeaTable Cloud ?

Construis une base de données-tableur dont la propriété déterminante est qu’elle reste rapide à un million de lignes.

Stockage : un moteur colonnaire plutôt qu’un stockage en lignes — DuckDB par-dessus des fichiers Parquet, un jeu de fichiers par table, avec un journal d’ajout pour les écritures récentes compacté sur un planning. Champs typés en texte, nombre, date, booléen, liste déroulante simple, liste déroulante multiple, et lien vers une autre table. Le système de types existe pour laisser la couche de stockage faire son travail, donc il est volontairement plus petit que ce qu’un produit à stockage en lignes pourrait se permettre.

Pourquoi ça compte, et quoi tester : filtrer, trier, grouper et agréger sont les opérations qui rendent une table utile et celles qui s’effondrent en premier à l’échelle. Livre une commande de benchmark qui génère une table synthétique d’un, dix et cent millions de lignes et rapporte les temps pour : un scan filtré, un groupement-et-somme, un tri sur une colonne non indexée, et une mise à jour d’une seule cellule. Publie ces chiffres dans le README. Un produit de base de données qui ne déclare pas sa propre performance demande qu’on le croie sur parole.

Grille : rendu virtualisé pour que le défilement d’un million de lignes soit fluide — seules les lignes visibles existent dans le DOM, avec une hauteur de ligne fixe pour garder les calculs de défilement triviaux. Redimensionnement, réordonnancement, gel de colonnes, et édition en ligne. Coller depuis un tableur vers une plage.

Vues : une vue est un filtre, tri, groupement, sous-ensemble de champs et hauteur de ligne enregistrés, nommés et partageables par URL. Grille, kanban groupé par un champ liste déroulante, et galerie. Les vues doivent être calculées par le moteur de stockage, jamais en récupérant chaque ligne et en filtrant dans le navigateur — c’est exactement ce qui casse à l’échelle.

Écrire à l’échelle : une modification d’une seule cellule s’ajoute au journal d’écriture et est visible immédiatement. Une modification en masse sur une sélection filtrée de cent mille lignes tourne comme une seule opération moteur avec un indicateur de progression et est transactionnelle. Importe un CSV d’un million de lignes avec une barre de progression et une déduction de type par colonne que l’utilisateur confirme avant validation.

Barre d’agrégation : des résumés par colonne (compte, somme, moyenne, min, max, compte distinct) calculés sur la vue actuelle, se mettant à jour à mesure que les filtres changent. C’est la fonctionnalité qui sépare le plus visiblement un stockage colonnaire d’un stockage en lignes, donc rends-la toujours visible.

API : un point de terminaison REST par table avec filtre, tri et pagination par curseur, ne retournant que les champs demandés.

Sauvegardes : export planifié des fichiers Parquet de chaque table plus le schéma, avec une restauration documentée et testée.

Hors périmètre : l’édition collaborative en temps réel, un système d’automatisation ou de plugins, une couche de construction d’applications, et tout déploiement multi-locataire hébergé. Note dans le README que la propre édition communautaire de SeaTable est open source et que l’auto-héberger est une alternative légitime à ce projet.