ср, 7 окт. 2020 г. в 10:51, Thorsten Schöning <tschoening@xxxxxxxxxx>: > > Hi all, > > I'm regularly reading that Postgres is often used with containers and > in cloud environments these days, even on some not too powerful NAS. > > What are the lowest resource setups you know of or even host Postgres > successfully with yourself? It's especially about RAM and CPU, if you > needed to e.g. configure anything special to make things somewhat work > in your stripped down environment etc. AFAIK the default configuration of Postgres is fairly conservative and may be a good starting point for such cases. > > Is there any point at which one is most likely forced to switch to > more specialized embedded databases like SQLite? E.g. because > Postgres requires a higher amount of resources because of it's > architecture? Or could Postgres in theory be used everywhere where > SQLite is used as well, as long as one is allowed to e.g. start an > additional process? For example, when you need to INSERT tens of thousands rows per second on your low-cost device SQLite is a choice. Postgres is a client-server with related overheads. Postgres requires deployment and configuration while SQLite just works with zero-configuration (which is a big advantage in case of IoT). Sure, in theory Postgres can be used instead of SQLite (and vice-versa). > > I would like to know if there's any realistic chance to use Postgres > in a low resources environment with little amount of RAM and somewhat > slow CPU like the following: > > http://ww1.microchip.com/downloads/en/DeviceDoc/ATSAMA5D27-WLSOM1-Datasheet-60001590b.pdf > http://ww1.microchip.com/downloads/en/DeviceDoc/SAMA5D2-Series-Data-sheet-ds60001476F.pdf > > One point is that I most likely need somewhat concurrent access to the > data, because of having web services exposing that data to clients, > daemons storing data locally only etc. OTOH, the number of concurrent > accessed won't be too high, there won't be too much load most of the > time. Things heavily depend on actual users of the device. Postgres' > architecture seems to better fit that use case than e.g. SQLite. In many cases concurrency is not a problem and in fact SQLite may handle concurrent requests faster than Postgres. Since SQLite is server-less and access overhead is near to zero (compared to Postgres) each writer does its work quickly and no lock lasts for more than a few dozen milliseconds. On the other hand, Postgres is better in cases of really high concurrency.
