Nick, it really would depend on your backup strategy and rotation, and a little understanding of relational databases helps here too.
Maintenance, whether it be SQL or ARCserve's own database will only trim what has passed the prune retention time (by default 30 days), but the prune job doesn't necessarily remove what you think it might or should.
More often than not it is only removing the references or pointers to the original information (there is a really long explanation into how it does work, but it's really won't add too much to this).
It's difficult to say how big your database could be without knowing what sort of stuff you are backing up and even then it would be a pure guess with no logic whatsoever. From experience it's a guess that 1.2Gb of CAT files could easily translate to 4-5 times that size if merged into the DB.
One thing to remember is that if you are using the catalog.db, then the CAT files are also pruned by the prune job as appropriate (if you're using at least r11.5) - I think that was the first version to automate this.
If your DB is likely to grow to 135GB even on a well specified, or even dedicated host/SQL Server it's something I would still personally avoid if possible - unless of course you frequently have to do urgent restores within a specific SLAs, or to conform to regulatory legislation.
Once the DB starts getting that big, the queries that the ARCserve application passes to SQL can be somewhat intensive and you could argue the DB requires some design rework to scale to anywhere near that size.
Should you get an error when the DB is that sort of size, or timeout even then this can start affecting your backups (media pools/rotations), and also things like inventory of your library (ARCserve references the DB when reading/storing media). This may show up rather obscurely as SCSI timeouts. Something you'd potentially only see if you were running an SQL trace at the same time as the library operation.
If you get some time check out this document:
It will give you a better insight into how ARCserve communicates with hardware, which is very different to what you're used to with BE. This is one of the things I always find people coming from using BE have a hard time getting past until they understand the differences in how hardware is handled.
Anyhow - good luck in converting - personally I've never used BE myself, but I have helped a few people convert to the ARCserve way of thinking through the years - it ain't gonna be easy - but hang in there and hopefully you'll see some benefit soon.
