4 ms·
There are exceptions to every rule but most of the time you're way better of when you use simple and reliable technology. If you need to copy something between
by gizmo 2y ago
There are exceptions to every rule but most of the time you're way better of when you use simple and reliable technology. If you need to copy something between servers you probably don't need anything more complicated than rsync. For blob storage you probably don't anything more complex than S3. For database backups do you really need multi-region streaming backups or does mysqldump suffice?
Every product has limitations. Well designed and simple products/tools have limitations that are easy to understand and easy to work around. The more complicated your architecture gets the more devilishly complicated the edge cases become. That's where you get punished for choosing complexity.
MySQL and Postgres are larger than Sqlite by more than an order of magnitude. What do you get in exchange for all those lines of code? Do you actually need the extra functionality? If you do, great. If you don't, choose the simplest solution that works. When you use simple tools changing your mind later is cheap.
- christophilus 2y agoProper concurrency, and the ability to scale out your applications across multiple servers / nodes. I’ve never worked on any application that had only a single web server, and yes, most of my applications have had to scale out a few times under load— even the smaller ones. Doing this with Postgres is trivial. Doing this with SQLite requires engineering. I’m not scared of engineering. I just don’t think it’s warranted when you have such an obvious, tried and true off the shelf database like Postgres available to you.
- deleted 2y ago[deleted]
- vidarh 2y agoScaling with SQLite and a datastore-per-user model is trivial. If you build your app as if it's using Postgres when you're using SQLite, then, yes, you'll suffer. If you pick SQLite, you should pick it because you will actually build your application in the way that makes most sense with SQLite. Datastore-per-user makes sharding/scaling trivial, and tends to drive an architecture that is easier to reason about. You're never going to e.g. accidentally leak data between users because of a broken query, for example.
- crazygringo 2y ago> MySQL and Postgres are larger than Sqlite by more than an order of magnitude. But they're still small, since you can run them on the smallest available cloud VM's and have plenty of memory/CPU/disk left over for webserving. > What do you get in exchange for all those lines of code? Do you actually need the extra functionality? The ability to scale beyond a single webserver. It's just as easy to use Postgres as SQLite, but by choosing SQLite you've made life much more complicated for yourself if you ever need to scale to two servers. Why would you inflict that headache upon yourself?
- kbolino 2y agoThe smallest available (burstable) instance type on AWS (t2.nano) has 1 vCPU, 3 CPU credits/hour (~= 5% average CPU utilization), and 512 MB of RAM. I don't think you're going to run very much on there and definitely not with room to spare.
- crazygringo 2y agoYou can run MySQL on that perfectly fine, together with Apache and PHP or something. If you've just got a small website without tons of traffic, it's no problem at all.