This! I'm surprised it took so long to somebody suggest an object store. On Dec 17, 2014 9:22 PM, "Jonathan Vanasco" <postg...@2xlp.com> wrote:
> > I wouldn't even store it on the filesystem if I could avoid that. > Most people I know will assign the video a unique identifier (which is > stored in the database) and then store the video file with a 3rd party > (e.g. Amazon S3). > > 1. This is often cheaper. Videos take up a lot of disk space. Having to > ensure 2-3 copies of a file as a failover is not fun. > 2. It offloads work from internal servers. Why deal with connections that > are serving a static file if you can avoid it? > > In terms of FS vs DB (aside from the open vs streaming which was already > brought up) > > I think the big issue with storing large files in the database is the > input/output connection. > Postgres has a specified number of max connections available, and each one > has some overhead to operate. Meanwhile, a server like nginx can handle 10k > connections easily, and with little or no overhead. While the speed is > comparable to the OS, you end up using a resource from a limited database > connection pool. And you run the risk of a slow/dropped client tying up > the connection. > Why allocate a resource to these operations, when there are more > lightweight alternatives that won't tie up a database connection ? > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
