41–50 of 119 posts
So he used a database 7 years ago that was about one year old at the time and had a bad experience with it and now continues to judge it to this day without tracking the evolution since, including schemas in the current release candidate.
No, the article isn't about Mongo. Quite the opposite.
> startup mistakes > .io domain oh my.
Earlier quoted context omitted.
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!
Yup, people stuck on optimising (or overthinking which datastore to use) before actually having a business are missing the point.
The worst code I worked with was at travel agency startup and they are REALLY successful now. It was REALLY REALLY bad and hard to maintain. The owner of the business just said: well, bugs happen. But when a customer (not too many of course) encounters one, they probably call the helpdesk. Sounds stupid, worked great, business wise.
4 years later, I am sure they still have problems with the crappy code, but the business is fine!
Earlier quoted context omitted.
TL;DR: "just use an MySQL or Postgres or SQLite"
Don't use SQLite for production, for all the love I have for it, the client libraries are usually locking accesses and don't work properly with concurrent reads/writes.
SQLite is also not too difficult to switch to a more advanced SQL in the future.
Just 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.
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 systems, but the most important thing for any startup is to get their idea validated as soon as possible.
Just 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.
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.
1) Use CouchDB and Postgres?
2) Somehow implement revisions and Postgres?
3) Use Postgres anyway and scrap the offline first?
Earlier quoted context omitted.
TL;DR: "just use an MySQL or Postgres or SQLite"
Don't use SQLite for production, for all the love I have for it, the client libraries are usually locking accesses and don't work properly with concurrent reads/writes.
Let's say "don't use it for production for a multiuser server app" then I agree. But that isn't really a supported scenario at all.
OP forgot the biggest mistake for choice of datastore: Blockchain.
Earlier quoted context omitted.
Oh, wait. So you should actually think about what you're trying to build and what would work best for it? I just read this hilarious blog post that said the opposite. This is all too hard, I'll just use Postgres(R).
By "Said the oppposite" do you mean this part?: > Think before you pick a database. If you insist on not thinking, pick PostgreSQL. Trust me.