Rowy et NocoDB sont souvent cités ensemble : les deux sont nés de l’idée « Airtable, mais en open source et sans limite de lignes ». En pratique, ce sont deux outils aux architectures différentes et aux trajectoires très dissemblables. NocoDB est une couche posée sur une base relationnelle qui transforme les tables en interface utilisable. Rowy est une couche low-code au-dessus de Firebase/Firestore, pensée pour les équipes produit qui ont besoin d’un backend sans développeur backend.
Nous les avons comparés sur la licence, les bases supportées, le self-hosting, l’API, l’automatisation, les prix et — souvent le critère décisif — l’activité de développement. Spoiler : en 2026, ce dernier point peut tout faire basculer.
Sites : rowy.io | nocodb.com
En bref
Points communs :
- code source ouvert et possibilité d’auto-hébergement ;
- une grille façon tableur avec des colonnes typées ;
- rôles et permissions, invitations d’équipe ;
- API REST et webhooks pour les intégrations ;
- une offre cloud gratuite et des forfaits payants par siège.
La différence tient au socle. NocoDB joue le rôle de frontend d’une base de données : vous créez une base dans NocoDB ou vous connectez une instance MySQL, PostgreSQL, SQLite ou SQL Server existante pour obtenir une interface confortable par-dessus. Les données restent dans votre base et NocoDB n’est que la couche de présentation et de collaboration.
Rowy fonctionne autrement : c’est un éditeur de données et un environnement de fonctions cloud lié à Firestore (NoSQL de Google Cloud/Firebase). Il propose des colonnes calculées, des champs d’action, des fonctions serverless en JavaScript/TypeScript et une API immédiate. C’est en substance un backend low-code pour une application, pas un outil pour exploiter la base SQL de l’entreprise.
D’où la conclusion : si vous avez déjà PostgreSQL ou MySQL, la question « Rowy ou NocoDB » se règle presque d’elle-même en faveur de NocoDB. Si vous construisez un produit sur Firebase et voulez un back-office sans code, Rowy est plus proche dans l’esprit, mais avec un risque détaillé plus bas.
Tableau comparatif
| Paramètre | NocoDB | Rowy |
|---|---|---|
| Licence | Sustainable Use License (usage interne et personnel gratuit, revente en tant que service interdite) | Apache License 2.0 |
| Stockage | Base NocoDB native ou MySQL, PostgreSQL, SQLite, SQL Server externes | Firebase / Firestore (NoSQL, Google Cloud) |
| Stack | TypeScript, Node.js | TypeScript, React, Node.js |
| Auto-hébergement | Oui : Docker, npm, manifestes Kubernetes | Oui, mais nécessite un projet Firebase et GCP |
| Usage principal | Interface pour données relationnelles, alternative à Airtable/Google Sheets | Backend low-code et CMS pour un produit Firebase |
| Vues | Grid, Gallery, Form, Kanban, Calendrier et interfaces (dashboards, pages) | Grid avec types de colonnes avancés, formulaires sur les forfaits élevés |
| Types de colonnes | Texte, nombre, date, liens entre tables, formules, pièces jointes, sélection | Plus de 30 types, dont colonnes dérivées et champs d’action |
| API | REST et GraphQL (v2 et v3), générées automatiquement | API REST automatique sur Firestore |
| Automatisation | Automations (déclencheurs sur enregistrement et planification), webhooks | Cloud Functions (JS/TS), champs d’action, webhooks, tâches planifiées |
| Bases SQL externes | Oui (forfait Business et supérieurs dans le cloud ; illimité en self-hosted) | Non |
| Offre gratuite cloud | 3 utilisateurs, 1 000 enregistrements, 1 Go | 1 projet, enregistrements illimités |
| Forfait payant | Plus 12 $/siège/mois (annuel), Business 24 $, Scale 45 $ | Pro 12 $/siège/mois |
| GitHub | 65 300+ étoiles, commits actifs (dernier en octobre 2026) | 6 800+ étoiles, dépôt déplacé vers buildship-ai/rowy, dernier commit en novembre 2024 |
| Risque d’abandon | Faible | Élevé |
NocoDB en détail
NocoDB a démarré comme « Airtable open source » et est devenu une plateforme pour outils internes : CRM, suivi de tickets, catalogues, inventaire, dashboards. Sa fonction phare est de s’appuyer sur une base SQL existante. Vous connectez MySQL ou PostgreSQL, NocoDB lit le schéma et génère l’interface : tables, formulaires, liens, vues. Aucune migration de données n’est nécessaire — un avantage majeur face à Airtable et aux SaaS similaires.
Les fonctions réellement utilisées
Vues et interfaces. Outre la grille, il y a Gallery (cartes avec visuel), Form (formulaire public qui écrit directement dans une table), Kanban (par champ de statut) et Calendrier. À part, les « interfaces » constituent un constructeur de pages où l’on assemble des dashboards pour les managers : graphiques, listes, boutons. L’offre gratuite inclut une interface de trois pages maximum ; les forfaits payants lèvent la limite.
Relations. Link-to-record, lookup, rollup et formules se comportent comme dans Airtable, mais sur un vrai schéma relationnel. Pour qui vient du SQL, c’est le compromis : une interface confortable, un modèle de données prévisible et portable.
API. NocoDB génère automatiquement des API REST et GraphQL pour chaque table : un frontend ou une application mobile accède aux mêmes données que l’équipe édite dans la grille. Les versions v2 et v3 coexistent, mais v2 est en fin de vie — les nouvelles intégrations doivent viser v3.
Automatisation. Déclencheurs à la création ou à la modification d’un enregistrement, actions planifiées, webhooks, intégrations e-mail et messagerie. L’offre gratuite autorise 100 exécutions par mois, Plus 30 000, Business 120 000, Scale 240 000. Ce quota compte : les automatisations par enregistrement le consomment vite.
Contrôle d’accès. Rôles au niveau de la base et de la table, invitations par e-mail, commentateurs séparés des éditeurs. Business ajoute les bases privées et le SSO SAML ; Scale, la sécurité au niveau des lignes et les journaux d’audit. Pour les entreprises soumises à des exigences de conformité, c’est essentiel, et les équivalents Airtable coûtent nettement plus cher.
Auto-hébergement
NocoDB se déploie avec une seule commande Docker, propose des images ARM (utile pour un Raspberry Pi ou un VPS modeste), une option npm et des manifestes Kubernetes. Un VPS de 2 Go de RAM suffit pour une petite équipe. Les limites cloud sur les enregistrements et les connexions externes ne s’appliquent pas en auto-hébergement : vous ne payez que l’infrastructure. C’est pourquoi NocoDB séduit les équipes qui sortent leurs données des SaaS étrangers.
Pour les entreprises en Russie, c’est un atout supplémentaire : le serveur peut venir d’un hébergeur local et les données restent dans la même juridiction. Le matériel requis est modeste, un VPS économique suffit — nous regardons généralement du côté de FirstVDS et Timeweb, où un conteneur démarre en quelques minutes.
Tarifs de NocoDB
- Free — 0 $ : jusqu’à 3 utilisateurs (3 éditeurs, 10 commentateurs), 1 000 enregistrements, 1 Go, 100 exécutions d’automatisation, 1 000 appels API/mois, une interface de trois pages maximum.
- Plus — 12 $/siège/mois en paiement annuel, en pratique 108 $/mois pour des sièges illimités au-delà de neuf utilisateurs : 50 000 enregistrements, 20 Go, 30 000 automatisations, 100 000 appels API, extensions et interfaces illimitées. Les connexions à des bases externes ne sont pas disponibles en Plus.
- Business — 24 $/siège, 216 $/mois pour des sièges illimités : 300 000 enregistrements, 100 Go, 120 000 automatisations, 1 million d’appels API, 10 connexions externes, bases privées, SSO SAML.
- Scale — 45 $/siège, 3 sièges minimum : 1 million d’enregistrements, 150 Go, 240 000 automatisations, 5 millions d’appels API, sécurité au niveau des lignes et audit.
- Enterprise — sur devis : provisioning SCIM, synchronisation des groupes depuis l’IdP, chargé de compte dédié.
Notez la logique « payez neuf sièges, les autres sont gratuits » : pour une équipe de 20 personnes, NocoDB Business revient moins cher que la plupart des concurrents facturés par utilisateur.
Les limites de NocoDB
- L’interface est dense ; les débutants cherchent les réglages pendant les premiers jours.
- Les performances sur de très grandes tables (millions de lignes) dépendent de la base externe : NocoDB n’est pas un entrepôt analytique.
- Plusieurs fonctions avancées (connexions externes, SSO, sécurité par ligne) sont réservées aux forfaits chers.
- Les automatisations sont moins souples qu’un vrai moteur de workflow ; la logique complexe reste du domaine du code.
- La Sustainable Use License n’est pas de l’open source classique : l’usage interne est libre, un service commercial public basé sur NocoDB ne l’est pas.
Rowy en détail
Rowy a été conçu comme l’arrière-cour de Firebase : une vue tabulaire des collections Firestore et la possibilité d’écrire des fonctions serveur depuis le navigateur. Pour une équipe produit sur Firebase, c’est réellement pratique : back-office, CMS et API apparaissent sans développeur backend dédié.
Fonctions
Intégration Firestore. Rowy se connecte à un projet Firebase et affiche les collections sous forme de tables. Les modifications dans l’interface arrivent en base et inversement : synchronisation bidirectionnelle, pas import/export.
Types de colonnes. Plus de trente : texte, nombres, dates, tableaux, géolocalisation, fichiers, références vers d’autres collections, plus les colonnes dérivées (valeurs calculées) et les champs d’action (boutons lançant une fonction cloud).
Cloud Functions. Des fonctions JavaScript/TypeScript écrites depuis l’interface, déclenchées par une modification d’enregistrement ou un bouton dans la ligne. C’est le scénario le plus fort de Rowy : envoyer un e-mail à la création d’une commande, calculer une remise, appeler une API externe.
Import et export. CSV, TSV, JSON et Airtable — import ponctuel et synchronisation continue avec Airtable sur les forfaits supérieurs. L’export est limité à 10 000 lignes en gratuit, illimité en Pro.
Recherche et filtres. La recherche plein texte et les filtres avancés sont des fonctions Pro.
Tarifs de Rowy
- Base — 0 $ : un projet, tables et enregistrements illimités, fonctions cloud et membres illimités, import/export, plus de 30 types de colonnes, audit au niveau des lignes.
- Pro — 12 $/siège/mois (10 % de remise en annuel) : projets illimités, recherche plein texte, export au-delà de 10 000 lignes, filtres avancés, clonage de code entre projets, plafond de dépenses GCP, support e-mail.
- Business — sur devis : domaine personnalisé, support prioritaire, versionnement des données, audit au niveau des champs, sauvegardes automatiques, formulaires.
La grille tarifaire paraît attractive, surtout l’offre gratuite sans limite d’enregistrements. Mais un détail change la donne : l’offre gratuite repose sur votre projet Firebase, donc les factures Firestore et Cloud Functions arrivent séparément, aux tarifs de Google Cloud.
Le risque principal : le développement s’est arrêté
Ce point pèse plus lourd que les qualités techniques. Le dépôt Rowy a été déplacé de rowyio/rowy vers buildship-ai/rowy, et le dernier commit date de novembre 2024. Pour un projet qui se présente comme un open source activement développé, cela fait près de deux ans de silence. L’entreprise a visiblement reporté son attention sur BuildShip, un constructeur visuel de workflows backend.
Ce que cela implique concrètement :
- aucune nouvelle fonction, aucun correctif de sécurité ;
- personne ne garantit la compatibilité avec les évolutions de Firebase/GCP ;
- la communauté Discord s’éteint et les questions complexes restent sans réponse ;
- si Rowy fait partie d’un processus de production, vous maintenez de fait un fork.
Pour un outil interne qui fonctionne et n’a pas besoin d’évoluer, c’est tolérable. Pour un nouveau projet en 2026, c’est un argument sérieux contre.
Autres limites de Rowy
- Couplage fort à Firestore : migrer vers SQL impose de réécrire le modèle de données.
- Le coût total, c’est l’abonnement plus la consommation GCP ; sur un projet actif, la seconde peut dépasser le premier.
- Aucune prise en charge des bases relationnelles externes (contrairement à NocoDB).
- L’auto-hébergement exige un projet Firebase et des comptes de service ; sans DevOps, c’est un obstacle.
Scénarios de test : comment choisir pour votre cas
Nous avons fait passer les deux outils par les tâches typiques que nos lecteurs nous apportent.
Scénario 1 : remplacer Airtable dans une équipe commerciale
Il faut une table d’opportunités, des formulaires web, un kanban par statut et des rôles pour les commerciaux et la direction. NocoDB couvre tout cela en Plus, avec les données dans votre PostgreSQL. Rowy le peut aussi, mais il faut déplacer les données vers Firestore : changer de stockage pour une interface. Gagnant : NocoDB.
Scénario 2 : une interface sur une base existante
Vous avez MySQL avec les données d’une boutique en ligne et voulez que le support consulte sans client SQL. NocoDB se connecte en lecture-écriture et affiche les tables immédiatement. Rowy ne sait pas le faire. Gagnant : NocoDB, sans discussion.
Scénario 3 : un back-office pour une application Firebase
L’application vit déjà sur Firebase, les données dans Firestore, et il faut un panneau pour le gestionnaire de contenu plus deux fonctions serveur. Rowy est prêt en une soirée : connecter le projet, choisir les collections, écrire une fonction. NocoDB exigerait une couche intermédiaire et de la synchronisation. Gagnant : Rowy — si le projet ne doit pas grandir pendant des années.
Scénario 4 : dix personnes, exigences strictes sur la localisation des données
Les données doivent rester sur votre serveur, avec piste d’audit et contrôle d’accès par ligne. NocoDB auto-hébergé le règle pour le prix d’un VPS ; dans le cloud, l’équivalent est en Scale à 45 $/siège. Rowy impose un projet GCP avec facturation étrangère. Gagnant : NocoDB.
Scénario 5 : prototype de backend le week-end
Formulaire, base, API et deux automatisations. Les deux conviennent ; Rowy démarre un peu plus vite sur Firebase, NocoDB est plus prévisible à maintenir. Le choix dépend de ce que vous exploitez déjà.
Coût sur des équipes réelles
| Équipe | NocoDB | Rowy |
|---|---|---|
| 3 personnes, jusqu’à 1 000 enregistrements | Free — 0 $ | Base — 0 $ + coûts GCP |
| 10 personnes, jusqu’à 50 000 enregistrements | Plus — 108 $/mois (annuel) | Pro — 120 $/mois |
| 20 personnes, jusqu’à 300 000 enregistrements | Business — 216 $/mois (annuel) | Pro — 240 $/mois + GCP |
| 50 personnes, SSO requis | Business — 216 $/mois | Business — sur devis |
| Infrastructure propre | Auto-hébergé, serveur seul | Auto-hébergé + Firebase |
Sur le papier, les grilles se ressemblent : 12 $ par siège chez les deux. Mais au-delà de neuf sièges payants, NocoDB cesse de facturer à mesure que l’équipe grandit, tandis que la facture Rowy augmente linéairement et que les coûts Google Cloud s’ajoutent. À 20–30 personnes, l’écart devient sensible.
Qui devrait choisir quoi
Choisissez NocoDB si :
- vous avez ou prévoyez une base relationnelle (PostgreSQL, MySQL, SQLite, SQL Server) ;
- vous voulez de l’auto-hébergement avec les données sur votre serveur ;
- la prévisibilité compte : développement actif, versions fréquentes, communauté vivante ;
- vous construisez des outils internes : CRM, inventaire, comptabilité, bases de connaissances tabulaires ;
- vous voulez formulaires, kanban, calendrier et dashboards au même endroit.
Choisissez Rowy si :
- votre produit tourne déjà sur Firebase/Firestore ;
- il vous faut un back-office avec des fonctions cloud JavaScript/TypeScript sans backend séparé ;
- le projet est interne et n’exige pas de développement à long terme ;
- vous êtes prêt à maintenir votre propre fork en cas de besoin.
Ne choisissez ni l’un ni l’autre si vous avez besoin d’analytique sur des dizaines de millions de lignes (c’est le terrain de ClickHouse et des outils BI) ou d’un vrai moteur de workflow avec branches et orchestration complexe (voyez n8n et similaires).
Verdict
En 2026, NocoDB est le pari le plus sûr. Il est activement développé, accepte des bases SQL externes, propose une tarification prévisible et ne vous enferme pas chez un fournisseur cloud. Pour la tâche typique — « donner une interface correcte à mes données et y donner accès à l’équipe » — il couvre 90 % des besoins.
Rowy reste un outil intéressant avec une idée élégante : la table comme interface vers Firestore, plus des fonctions serveur dans le navigateur. Si vous êtes déjà dans l’écosystème Firebase et qu’il vous faut un back-office cette semaine, Rowy livrera. Mais miser un nouveau projet pluriannuel dessus est risqué : près de deux ans sans commits, c’est un signal qu’on ne peut pas ignorer.
Notre recommandation : commencer par NocoDB et considérer Rowy comme une solution tactique pour une tâche Firebase précise, avec un plan B si le support s’arrête définitivement.
Et vous, de quel côté êtes-vous — déjà utilisateur de l’un de ces outils ou encore en train de choisir ? Dites-nous quelle tâche vous voulez résoudre ; d’après l’expérience des lecteurs, on voit vite où chaque outil atteint ses limites.