Earlier quoted context omitted.
No, the article isn't about Mongo. Quite the opposite.
Well, this discussion here is now about Mongo
Regrettably :(
Startup Mistakes: Choice of Datastore
51–60 of 119 posts
Re: Startup Mistakes: Choice of Datastore
#52> startup mistakes > .io domain oh my.
What's the problem with a .io domain? Honest question.
There was a recent failure that affected everyone using the TLD and a popular blog post explaining it and suggesting that you use something more reliable. Some of the comments on the article pointed out that the same company runs .org and a handful of other reliable TLD's.
Re: Startup Mistakes: Choice of Datastore
#53To the people saying "just do Postgres", what would you say to a startup that wants to create offline first apps? CouchDB, for example is way better at that than Postgres. 1) Use CouchDB and Postgres? 2) Somehow implement revisions and Postgres? 3) Use Postgres anyway and scrap the offline first?
If you want to create offline-first apps, I would use Postgres as the main datastore and use Couch to sync data between client and server. You'd have to decide which of your data would live where (or if you wanted to use Couch as a way to transfer data from the server to the client).
Couch is a very good datastore for that use case, though, so I would definitely use it in some capacity for your purpose.
Re: Startup Mistakes: Choice of Datastore
#54Earlier quoted context omitted.
Unfortunately, no. Some friends of mine picked another nonrel database (not Mongo) for their new company, which prompted this article. I still have to give this advice quite often.
I think that there are various reasons to pick DBs. Blindly picking a SQL DB (mysql/postgres etc.) is quite expensive from the get-go (a production ready mysql/postgres would cost ~30$/m). Mongo costs ~$10/m (MongoDB Atlas), Google's Datastore is Pay as you Go (so your initial cost is close to $0 till you get paying customers), AWS's DynamoDB is similarly priced as well. Sure, sadly all those noSQL solutions get real…
$30/month doesn't seem "quite expensive" to me, not if it saves you a single hour of developer time each month. If that is breaking the bank then you're already in trouble. In the case of a company in heavy development mode you can run the database locally or on a cheap $5 VM. Databases are pretty easy to migrate around when they're not in production and can be taken offline.
Re: Startup Mistakes: Choice of Datastore
#55Earlier quoted context omitted.
BIG ERROR. Like, MONUMENTAL. That something (if chose very wrong) will totally derail you progress and will cost a lot of fix it later. Is incredible. Nobody remember that the most cost effective way to fix a problem is in the early stages? And, yes, the best overall primary datastore, like 90% of the cases, is a RDBMS. Very few actually need to use something else.
Yes and no. Yes, choose carefully at the beginning, and use relational. More specifically, use Postgres. But choose the right things to worry about at the beginning. So worry about something that can accommodate changing requirements, i.e., a relational database. Don't worry about scalability. You will be very, very lucky to ever have that problem. Worry about it then.
Also, if you find that some data is better suited for some other datastore, just move that data off. For example, I start with Postgres but almost always end up storing session data in Redis, for a bit more speed.
Re: Startup Mistakes: Choice of Datastore
#56Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
Agree! Most of us techies think tech is more important than sales. We also loathe bad design decisions. But your customers (in most cases) don't care! But I always wonder exactly "what" is easier with mongo or another NoSQL db. Just get a relation db like PostgreSQL, MySQL or SQLite for that matter. If your site starts to get performance problems go to the pub, celebrate a bit of success and then optimise!
People starting a business need to be able to consider more than one thing at a time.
Re: Startup Mistakes: Choice of Datastore
#57Earlier quoted context omitted.
Hmm, how are you deploying things that a database costs $30/m? I just put it on the same server as the application worker and split it off if I need more performance later.
maybe I'm doing this wrong, but if I use RDS / Cloud SQL / Compose etc - a normal base cluster + another failover cluster + hourly/daily backups (based on your release schedule) all add up to around 30 - 50 based on various cloud providers.
You can start with one server with postgres installed on it and when you need to scale to multiple application servers, you can run postgres on another server.
For backing up postgres, all you have to do is setup a cron job that backs up the postgres' data directory to S3/Google Drive/Dropbox every hour/day.
If you want proper replication and failover then you can probably use 2 digital ocean droplets each for $5/month and another $5 VM for the application server itself.
Re: Startup Mistakes: Choice of Datastore
#58Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
BIG ERROR. Like, MONUMENTAL. That something (if chose very wrong) will totally derail you progress and will cost a lot of fix it later. Is incredible. Nobody remember that the most cost effective way to fix a problem is in the early stages? And, yes, the best overall primary datastore, like 90% of the cases, is a RDBMS. Very few actually need to use something else.
The point OP is making is that in a startup, you don't do engineering for the sake of engineering. In the end, what matters is generating wealth.
Obviously, you want a sane legacy for the future but unless you already have hit that sweet product-market fit spot it is likely that you will spend a non-trivial amount of time optimizing (prematurely) for something that's in fact orthogonal to what you actually need.
The trick, as usual, is to balance engineering and business depending on which stage your at.
Re: Startup Mistakes: Choice of Datastore
#59Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
I don't disagree, but you'd probably rather pick "something" tried, true, and appropriate for most use cases, and that's RDBMS in this case.
Re: Startup Mistakes: Choice of Datastore
#60Earlier quoted context omitted.
BIG ERROR. Like, MONUMENTAL. That something (if chose very wrong) will totally derail you progress and will cost a lot of fix it later. Is incredible. Nobody remember that the most cost effective way to fix a problem is in the early stages? And, yes, the best overall primary datastore, like 90% of the cases, is a RDBMS. Very few actually need to use something else.
What's the use of fixing something in a cost effective way if your startup is going to fail anyway? You need to validate and test first. Get customers ASAP. If that means writing shitty code and using a shitty database or not even a database at all, than that's great. You can always convert to a better system afterwards. I do agree that the longer you wait, the harder it gets to rewrite code and convert to different…
This is just the balance fallacy. Relational and document databases aren't equally likely to be the type you need. Most of the times you have relational data, so you want relational databases. Pick the datastore that's more likely to fit your data from the start.