4 ms·

I feel the opposite way. If your application's data layer is sensibly designed, it shouldn't be too bad to switch to postgres when you need to. It may be tediou

by bkanber 13y ago

I feel the opposite way. If your application's data layer is sensibly designed, it shouldn't be too bad to switch to postgres when you need to. It may be tedious if you have a large codebase, but it won't be difficult. I think the up-front benefits of using mongo (especially as a sole developer/devops/sysadmin person) outweigh the difficulty of the changes you'll need to make later on, which will only happen as you hit scale and have more resources to nurture the devops side of the tech stack.

dboat 13y ago
This prototyping story sounds to me like admittedly shooting yourself in the foot if your prototype turns out to be worth a damn. Basically, you're saying mongo is an excellent choice only when your storage backend is a moot point. I can't think of any codebases I've seen where intentionally choosing the storage backend you know you don't want to use (if the project is successful) would be a reasonable thing to do. Understate it if you must, but having to change your backend from mongo to postgres is not a desirable situation. Besides, if you're going to use postgres to scale, use it's features and write well optimized queries for it. The difference between a bad massively complex query and a well optimized one can be several orders of magnitude, and that optimization can indeed be difficult. It goes without saying that you wouldn't leave that to an ORM.
- nostrademons 13y ago
  The advantage of shooting yourself in the foot if your prototype turns out to be worth a damn is that it forces you to rewrite it with more rigorous development practices ASAP. Usually, choice of a storage engine isn't the only problem with a throwaway MVP - you've probably written it in a language that won't scale, and skimped on error handling, and are using really inefficient algorithms, and didn't bother documenting anything. That said, I would use PostGres for my MVPs, using it as a key-value store initially until its more clear what the schema should be. That is, if I still bothered using code for prototypes; of late I've been more fond of napkins and Adobe Fireworks.

by bkanber 13y ago

dboat 13y ago

This prototyping story sounds to me like admittedly shooting yourself in the foot if your prototype turns out to be worth a damn. Basically, you're saying mongo is an excellent choice only when your storage backend is a moot point. I can't think of any codebases I've seen where intentionally choosing the storage backend you know you don't want to use (if the project is successful) would be a reasonable thing to do. Understate it if you must, but having to change your backend from mongo to postgres is not a desirable situation. Besides, if you're going to use postgres to scale, use it's features and write well optimized queries for it. The difference between a bad massively complex query and a well optimized one can be several orders of magnitude, and that optimization can indeed be difficult. It goes without saying that you wouldn't leave that to an ORM.

nostrademons 13y ago
The advantage of shooting yourself in the foot if your prototype turns out to be worth a damn is that it forces you to rewrite it with more rigorous development practices ASAP. Usually, choice of a storage engine isn't the only problem with a throwaway MVP - you've probably written it in a language that won't scale, and skimped on error handling, and are using really inefficient algorithms, and didn't bother documenting anything. That said, I would use PostGres for my MVPs, using it as a key-value store initially until its more clear what the schema should be. That is, if I still bothered using code for prototypes; of late I've been more fond of napkins and Adobe Fireworks.