To be clear - the document binary object is stored in Appian's filesystem, and only the key (the document id) is stored in the CDT, that is, a reference or 'pointer' to the document so if you're concerned about the size of the CDT because it references a document you should not be concerned. 

Thanks for your reply Stewart. Our application is using a!fileUploadField to receive a .XML file which is stored as document. The document is then loaded into a CDT. When the XML being uploaded has a size bigger than 1MB, we are displaying error to the user because we worry that anything bigger will have a problem with performance. I think the worry came from a similar upload business function where there is a need to UPDATE existing records so a query rule is used and that is causing size problems. This XML upload is different because it is going to CREATE records. Our users are asking to remove the limit of 1MB. Based on your reply, we should be able to grant the users request without compromising performance.

Thanks for your reply Stewart. Our application is using a!fileUploadField to receive a .XML file which is stored as document. The document is then loaded into a CDT. When the XML being uploaded has a size bigger than 1MB, we are displaying error to the user because we worry that anything bigger will have a problem with performance. I think the worry came from a similar upload business function where there is a need to UPDATE existing records so a query rule is used and that is causing size problems. This XML upload is different because it is going to CREATE records. Our users are asking to remove the limit of 1MB. Based on your reply, we should be able to grant the users request without compromising performance.

So (again, to be clear) there WILL be a performance overhead in allowing larger files to be uploaded - it's just a fact:a larger file will take longer to upload than a smaller one. But once uploaded there should be no difference to the performance of writing a CDT to a datastore that references that document as the document ID will be just cast to an integer (you should be able to see this if you look at the database column where the document id is stored).

Thank you! The CDT and datastore will not have the documentid, the document will just be residing in the knowledge center. Is there a maximum file size when executing a!fileUploadField?

I forget whether there's a hard limit for the uploaded file size, and if so it's quite large - in reality the limit will probably be the practical limit - i.e. the size a user is likely going to be able to upload before connection interruption issues or browser timeout issues interfere, around the "a few gigabytes" level at the most.

Hi Sheila - so I'm a little baffled as to how you will be able to correlate any data in your datastore to any document(s) in the KC without the database record having the documentid in it? That is: how will you ever find the document again in your application? There are other ways (e.g.search using some pattern for the document name) but such things are 'fragile' to change, whereas the documentid is immutable.

Thanks Mike!

Stewart, upon upload, the document is dissected and put in CDT that is used for further massaging into usable CDTs that are stored in the datastore.