Why you should probably be using SQLite

Re:Why you should probably be using SQLite by wongarsu on Friday October 27, 2023 @10:08AM (#38038614)

There is one edge case where comparison makes sense: read only workloads. If you have a large, mostly static database (e.g. a car parts website) it can make sense to just sync a Sqlite file across all your servers.

On the other hand, read replicas are also the easy case for database clusters. And just making your one database server bigger also scales a lot, there is nothing stopping you from adding a terabyte of RAM.

[ Parent | on HN ]

Re:Why you should probably be using SQLite by JohnBooty on Friday October 27, 2023 @10:26AM (#38038885)

    And just making your one database server 
    bigger also scales a lot, there is nothing 
    stopping you from adding a terabyte of RAM.

Underrated development strategy. If your max envisioned workload won't exceed what a single server can reasonably handle, this is orders of magnitude easier&cheaper&performant than anything else.

Additionally, I think a large percentage of the HN crowd underestimates what a single large-ish single server can handle these days. Probably because we are all used to only seeing tiny virtualized slices these days.

192+ threads, 2TB of RAM, terabytes of crazy fast PCIe storage. This was multiple racks of servers not too long ago, now in ~2U and it costs less than a car.

[ Parent | on HN ]

Re:Why you should probably be using SQLite by qaq on Friday October 27, 2023 @12:54PM (#38040911)

You can get Dual AMD EPYC™ 9634 Processor 84-core 2.25GHz 384MB Cache with 3TB RAM and 200TB of SSD storage for less than a car. So 336 threads in 2u box it's really crazy.

[ Parent | on HN ]