Comment savoir si SQLite suffit ou s'il faut passer à PostgreSQL?
#1
Je suis en train de refondre une petite application interne pour mon équipe, et je me retrouve bloqué sur un choix qui a l'air tout bête. Actuellement, tout est dans un seul gros fichier JSON, mais avec les nouvelles fonctionnalités, ça devient ingérable. J’ai commencé à mettre en place une base de données SQLite, c’est léger et ça semble parfait pour la taille du projet. Mais voilà, en en parlant autour de moi, on m’a dit que pour un outil qui pourrait potentiellement être utilisé par plusieurs services plus tard, je devrais peut-être partir directement sur PostgreSQL. Ça me paraît un peu overkill pour l’instant, et je ne suis pas à l’aise avec l’administration d’un vrai serveur de base de données. Je ne sais pas si je complexifie inutilement les choses en visant trop large, ou si au contraire je me prépare des problèmes en restant trop simple.
Répondre
#2
Pour demarrer vite et eviter les aller-retours SQLite est tres pratique car il n y a pas de serveur et le fichier unique simplifie les migrations et les tests. En revanche pour un outil qui peut servir a plusieurs services PostgreSQL offre des controles d acces des transactions robustes et des outils de supervision. Si votre objectif est d aller vite restez sur une base de donnees legere mais si vous envisagez l echelle et le partage des donnees prenez PostgreSQL au moment ou vous passez a l echelle.
Répondre
#3
Franchement j ai grandi avec SQLite et j avoue que PostgreSQL me fait peur a la fois. Le plus important est de rester simple aujourd hui et de prevoir demain si besoin. Si le besoin multi service n est pas en vue tout de suite SQLite suffit et on peut evoluer plus tard si besoin. Vous ne vous sentez pas pressé d installer tout un serveur maintenant ?
Répondre
#4
Le vrai probleme ici est peut etre de reformuler ce qu on cherche a faire on peut se demander si on code pour gagner du temps aujourd hui ou si on prepare deja une architecture pour plusieurs services. Dans ce cadre une base de donnees peut rester simple ou devenir un outil puissant selon l evolution du projet.
Répondre
#5
On ne devrait pas accepter a priori que tout projet court se tourne vers un serveur de donnees complexe PostgreSQL peut etre utile mais il n est pas une obligation et il faut peser la charge et l autonomie de l equipe. On peut commencer avec SQLite et ajouter une base de donnees plus robuste plus tard si les besoins evoluent. Est ce que vous avez une estimation des services envisageables et de leur charge ?
Répondre
#6
Pour planifier il faut penser migrations et modularite c est ce que PostgreSQL offre mieux surtout avec des outils avances et la capacite a gerer des schemas varies et un schema evolutif. SQLite reste limitant sur certains alter et sur les migrations orientees. Une idee peut etre de dessiner un schema de reference sans lien direct et de tester le flux d integration continue.
Répondre
#7
Plan en trois etapes commence par SQLite puis ecris une couche de migration et prepare un passage a PostgreSQL pour le jour ou tu auras besoin de separation des services et de scalabilite. Pense aussi a la base de donnees et a la gestion des droits et des backups.
Répondre


[-]
Réponse rapide
Message
Saisissez votre réponse à ce message ici.

Code de confirmation
Veuillez saisir le texte figurant dans l’image ci-dessous. Ce procédé permet de bloquer les robots.
Code de confirmation
(insensible à la casse)

Aller au forum