Performance implications of DB size?

Continuing the discussion from Database size:

I have been attaching PDFs to various transactions as a matter of convenience; this, of course, makes the database size increase.

Disk storage is not an issue whatsoever, but before I continued making this a regular part of my practice I wanted to find out if there were any negative performance implications of using Manager to store large numbers of PDFs. Is there any guidance on this?


1 Like

As far as have seen, the number and size of attachment has no direct impact on db performance. They appear to be unrelated.

However, even if the attachments reach a ridiculously large size at some point, you can still manage them in attachment type.

So far as I know, this could marginally affect the time it takes to create backups. There is no reason it should affect other operations.

I wonder why symbolic links aren’t used just like other programs do? :thinking:

Using symbolic links would mean that if you imported your business to another computer, you would not have the attachments as well and would have transfer them all separately.

Not a task to be taken lightly unless you are an extremely disciplined user

And can afford lots of unpaid time.

I don’t know the actual justification, but there’s certainly an audit trail concern - if you use symbolic links, then you can change the linked document at your pleasure and has no way of knowing about it (short of going to extra lengths such as hashing.) As it is now, adding and deleting attachments shows up in the history log. A number of governments have passed regulations requiring bookkeeping programs to have an audit trail, so I suspect this is part of it.

On a personal level, having used some programs which DO use links – it’s a real pain when you forget that you linked something, move it, and now you’ve broken everything.

Why not? The link to a file in the cloud stays the same, doesn’t it?

yes, but not everyone stores their attachment in the Cloud

I don’t believe the small number of PDF documents you manually add to the SQLiite database will come anywhere near it’s limits.

I assume because that’s going in the opposite direction to the philosophy Manager appears to be taking. All changes I have seen in Manager try to hide internal complexity from the end user. Using SQLite enables all of a Managers business records to simply be one file. All internal requirements are managed by the software.

More recently most of the program level settings have also been moved to the single business file and the business file has been given human readable names.

So no, I don’t think using symbolic links would be a step forward. Going in the opposite direction has some merit, removing links to external images and instead storing the images in Manager’s data file. Possibly by adding a custom field type image for inventory items.


Hardly any negative (or positive) performance implications. Modern filesystems are sophisticated database engines just like SQLite.

1 Like

Agree, as this is also a security issue. @lubos ?