zlacker

>>redbel+(OP)
It seems like Postgres isn't really doing anything here in the benchmark besides acting as a host for XGBoost? It needs to load the model parameters from the database whereas the Python microservice is reading the model parameters from a model.bin file in the filesystem. Both are one-time costs presumably (I'm guessing the SQL that loads the model keeps the model around in memory which seems reasonable given its performance gap to Python).

So it seems like what is needed is a better host for XGBoost models instead of having to install, maintain and launch an entire database? Or am I missing something here?

>>localh+d9
I think what you're missing is that XGBoost is worthless without data to use for inference. That data can come from in process, or over the wire. One is fast, one is not.

>>montan+Aa
Well, imagine nginx plugin that runs XGBoost. Or even standalone Rust/C++ microservice which provides XGBoost via standard http interface. The data might come from filesystem, or loaded from network location on startup/reload and kept in memory.

Basically, postgresql is a stateful service, and stateful services are always major pain to manage -- you need to back them up, migrate, think about scaling... Sometimes they are inevitable, but that does not seem to be the case here.

If you have CI/CD set up, and do frequent deploys, it will be much easier and more reproducible to include models in build artifact and have them loaded from filesystem along with the rest of the code.

>>theamk+Rf
Stateful services are indeed more painful to manage than non stateful ones. Ignoring state (data fetch time) for ML as if the model artifact is the only important component is... not a winning strategy.