If the DB was on the local machine, then the performance difference between the DB software reading (and caching) 300KB from the disk is not going to appreciably different than the OS reading (and caching) 300KB from the disk.

In the example you linked to, 24GB of 32GB (75%) of the data set was this XML data. If that 24GB was moved to a memcached farm (or other RAM-based clustered caching solution), then performance would likely be better across the board vs. a disk-based solution, assuming a LAN connection between hosts and a normal distribution of requests to chunks of XML.

Maintenance of the database will be faster and simpler without that extra 24GB of data to push around. Not sure how Postgres does “ALTER TABLES” but MySQL always makes a full copy of the table…

As usual, the answer is “it all depends” based on performance need, nature of the system, and available resources.

So you would stick 300kb of text in the file system too?

Well, in *a* file system. May be on the DB server, may be on a different host. If your DB serves to lookup which blob you’re interested in using, then there’s a more efficient system to serve the blob, as long as the blob is large enough so that it can be fetched or stored or replicated more efficiently than in the RDBMS.

What, exactly, do you use your database for?

This gets nicely at the fuzzy area between data that is efficiently stored and retrieved in the DB and those that are not. That size threshold will vary based on lots of factors. 300KB is very very likely to be larger than what is efficient.

This is not a black and white issue when details of the application, platform software, and hardware are not known.

What, exactly, do you use your database for?

What’s the difference between 300kb of XML or 300kb of text?

Absolutely no difference, unless as you’ve said the DB can make use of the XML as a native type.

It would be a very very special case app for which this architecture would make sense.

I also question whether or not it will actually improve “performance”. Which performance? It may improve database scalability, but that is only one component of the system.

File system storage has its own mixed bag of issues… good for some things, not for others. While I personally store binary assets like images on the filesystem and use the database to provide a pointer, I don’t think it’s a blanket solution. It’s an option but in my opinion by no means a best practice.

Something like that should be stored outside of the DB, named with the row’s primary key value. It’s a tiny bit more work to implement, but will pay off in database scalability, performance, and overall system flexibility.