3 ms·
"If you're used to servers written in interpreted languages (or named after precious gems), prepare to be pleasantly surprised by PostgREST performance." then
by al2o3cr 12y ago
"If you're used to servers written in interpreted languages (or named after precious gems), prepare to be pleasantly surprised by PostgREST performance."
then
"Ultimately the server (when load balanced) is constrained by database performance. This may make it inappropriate for very large traffic load."
ROFL. Bragging about performance, then "but don't use it for anything big". So instead of getting a solution which scales out with app servers in the "language named after precious gems" (straightforward), you get to scale out Postgres servers (not straightforward).
- twic 12y agoHold on, do you think the Ruby implementation would not be constrained by database performance? That would be impressive indeed. The author's point is just that the implementation is fast enough that it will never be the bottleneck.
- zentrus 12y agoI'm not sure if this is exactly where al2o3cr was going, but a Ruby (or whatever) application would normally include such things as caching and queueing. Despite the slowness of Ruby et al, I actually would expect a modern application with these layers to handle load much better than straight database calls. So I guess I would consider the PostgREST implementation a bottleneck because you can't add any of these layers.
- icebraining 12y agoWhy couldn't you add a plain HTTP caching layer (e.g. Varnish) on top of PostgREST?
- zentrus 12y agoYes, you could. My only point is that PostgREST limits you in what you can do in terms of handling load.
- joevandyk 12y agoMarshaling json and the ORM in Ruby is very likely to be the bottleneck in high-traffic api's. This application takes the role of rails in an api. If you have a rails or python or whatever api backed by a PostgreSQL database, postgrest is basically no different.