61–70 of 119 posts
—
Meta-comment: Feel like if the poster is self-identifying as the author when posting the link, it’s verified via say email/domain, an HN username has been ID’d in the past as the author, etc. — it should be automatically obvious in post, comments, etc.
Earlier quoted context omitted.
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.
If your site is light on writes and always will be, I think SQLite is a good choice. Especially if it reduces the complexity of the system up front. I use it for a lot of personal projects that never gain more than a few thousand impressions a month. SQLite is also not too difficult to switch to a more advanced SQL in the future.
Earlier quoted context omitted.
Yup, people stuck on optimising (or overthinking which datastore to use) before actually having a business are missing the point.
Or they miss the point when overthinking the whole code for the program/website. Get it done. Start finding customers. 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 stu…
OP forgot the biggest mistake for choice of datastore: Blockchain.
Earlier quoted context omitted.
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.
It's designed for single client, and works very well in production for single client. Mobile apps, desktop apps, and anywhere you can serialize access it works great. 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.
I feel like MongoDB/NoSQL is a horse that's been beaten so much in the last few years that no one is actually making that choice nowadays. Hasn't everyone already learned to stick with Postgres?
MongoDB/NoSQL is deployed and used at large scale by companies like Facebook, Ebay and many others. That's quite far from "no one is actually making that choice nowadays".
Earlier 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.
Wouldn't NoSQL be better suited for this scenario? Genuinely curious.
I use both MySQL and MongoDB in my daily work on a classifieds site that does a few hundred million pageviews a month. Both are pretty solid performers. The article is correct that with Mongo you just move the schema into the code (new versions not withstanding). I think it's nicer to have the schema on the database side but it's really just user preference. We typically end up creating a schema class and defining it up-front anyway. There is also a small subset of cases where not having a schema at all is actually a benefit.
Starting with a popular SQL engine is a really good tried and tested method though.
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.
The cost is that access through network e.g. NFS or SMB in wal mode is impossible (but you shouldn't have done that anyway), and that you can't just ship the sqlite file - ship a dump/backup instead, or you'll have to do recovery on the wal file you sent.
Of course, it's a good idea to use pgsql from the get-go; but SQLite deserves more credit than it gets, and is much more capable than it is usually assumed to be.