What this article covers
Which database LinkFixer Advanced needs for a given migration job, and specifically whether Microsoft Structured Query Language (SQL) Server Express is acceptable or whether SQL Server Standard is required.
The question recurs because LinkTek's own documentation is easy to misread in either direction, and because SQL Server licensing carries real recurring cost. This article quotes LinkTek's wording verbatim, confirms the relevant Microsoft edition limits against Microsoft's own documentation, and sets out how to size the decision for any job.
Last verified against LinkTek and Microsoft documentation in August 2026.
The short answer
- Under 100 gigabytes: the built-in SQLite database is sufficient. No SQL Server needed.
- Over 100 gigabytes: SQLite is out. A SQL Server connection is required.
- SQL Server Express is permitted, not forbidden. LinkTek explicitly name Express as satisfying the requirement for migrations over 1 terabyte, and separately describe it as functional. It is not a technical block.
- LinkTek do not recommend Express and warn it is very likely to cause performance bottlenecks.
So the choice between Express and Standard is a performance trade, not a hard technical prohibition. Anyone who says LinkFixer cannot run on Express is overstating the vendor's position. Anyone who says Express is a recommended production configuration is also overstating it. The real case against Express rests on Microsoft's documented Express ceilings, covered below, not on any vendor prohibition.
The vendor wording, quoted verbatim
All quotes below are LinkTek's own text from their public help desk.
On production installations
All Production installations will require that you connect LinkFixer Advanced to a Microsoft SQL Server 2012 SP4 or newer SQL Server. We do not recommend using Microsoft SQL Express. It has limitations which are very likely to result in performance bottlenecks.
On migrations over 1 terabyte
NOTE: Microsoft SQL Server 2012 express or above is required for migrations over 1 TB in size.
Note what this sentence does. It names Express as meeting the requirement for the largest jobs. It does not exclude Express.
On the default SQLite database
The default database installed by LinkFixer Advanced is SQLite, which is suitable for testing and for small production jobs up to 100 gigabytes. SQLite is a file-based database and is not sufficient for processing larger numbers of files and links.
On multiple servers and the Inoculate process
SQL Server allows you to connect your multiple servers to the same database which is required for the Inoculate process.
On Express performance
(Note: SQL Server 2016 Express will underperform but is functional)
This is the most important line for settling the argument. LinkTek's own word for Express is "functional".
Sources
- LinkFixer Advanced System Requirements
- LinkFixer Advanced software and system requirements
- LinkFixer Advanced hardware requirements, CPU, RAM, disk space
What this means in practice
Read the vendor position as three separate statements, because conflating them is what causes the argument:
- SQLite has a hard ceiling. 100 gigabytes. Above that it is not a judgement call, it is out. This one catches people, because SQLite is the default and nothing warns you at install time that you are on a database with a documented ceiling well below most real migration jobs.
- Express is allowed. LinkTek name it for jobs over 1 terabyte and call it functional. There is no licence check, no supported-configuration gate, and no refusal to support you for running it.
- Express is not recommended. LinkTek expect it to underperform and to bottleneck, but they do not say why in any specific terms. The next section supplies the specifics.
The SQL Server Express ceilings, confirmed against Microsoft
LinkTek warn that Express "has limitations" without naming them. Those limitations are documented by Microsoft, in the Scale limits table of Editions and supported features of SQL Server 2022. They are worth knowing in the right order, because the one most people reach for is not the one most likely to hurt.
1. Buffer pool cap: 1,410 megabytes
Microsoft give Maximum memory for buffer pool per instance of SQL Server Database Engine as 1,410 MB for Express, against 128 GB for Standard.
This is the constraint that actually explains LinkTek's bottleneck warning, and it is the first one to check. The buffer pool is the database engine's working memory cache. On a link inventory of any size, an engine limited to roughly 1.4 gigabytes of cache will be reading from disk constantly instead of serving from memory. That is a throughput problem that appears immediately and gets worse as the job grows. It does not wait for any size threshold to be crossed.
2. Compute cap: the lesser of 1 socket or 4 cores
Microsoft give Maximum compute capacity used by a single instance as limited to lesser of 1 socket or 4 cores for Express, against the lesser of 4 sockets or 24 cores for Standard.
This one interacts badly with LinkTek's own hardware guidance. Their consolidated requirements article sets a minimum of 8 processors. An Express database engine on such a machine can use no more than 4 of those cores, so half the specified processor capacity is unavailable to the database regardless of how the machine is sized. Paying for a machine built to the vendor minimum and then capping the database at half of it is a poor trade.
3. Database size cap: 10 gigabytes
Microsoft give Maximum relational database size as 10 GB for both Express and Express with Advanced Services, against 524 PB for Enterprise, Standard and Web.
This is the limit most people cite first, and it is real, but it is the least useful of the three for planning. See the next section for why.
Why the 10 gigabyte cap cannot be used to predict failure
The 10 gigabyte cap applies to the LinkFixer database itself, not to the volume of content being migrated. LinkFixer's database holds the file and link inventory, so it grows with file and link count, not with the size of the files. A migration of several terabytes made up of a modest number of very large files may keep the database well under 10 gigabytes. A migration of similar volume made up of many small, heavily cross-linked Office files will push it much harder.
If the cap is reached, Express does not degrade gracefully. The database stops accepting writes and the job fails outright rather than merely running slowly.
But this cannot be forecast, and should not be asserted as though it can. LinkTek publish no ratio of content volume, or file count, to resulting LinkFixer database size. Without that ratio there is no way to calculate in advance whether a given job will breach 10 gigabytes. Treat it as a known and quantified risk of the Express option, not as a proven blocker, and request a sizing estimate from LinkTek for any job where Express is under serious consideration.
This is why the buffer pool cap deserves top billing. The 10 gigabyte limit is a risk that may or may not materialise. The 1,410 megabyte buffer pool is a certainty that applies from the first pass.
The vendor documentation is inconsistent. Read this before revising the position.
LinkTek's three requirements pages do not agree with each other. Anyone reading only one of them will reach a different conclusion, and may try to revise a specification downward on the strength of the weaker page.
| Requirement | Consolidated System Requirements article | The other two pages |
|---|---|---|
| Operating system | Windows 10 or Windows Server 2012 R2 | Windows 7 or Windows Server 2008 R2 |
| Processors, minimum | 8 processors | 4 processors |
Follow the consolidated System Requirements article. It is the most recently updated of the three and it is the stricter one. The older pages should be treated as superseded, not as an alternative permitted specification.
If someone quotes the 4-processor or Windows 7 figures, they are quoting a stale page. Point them here.
How to size the decision for any job
Work through these in order.
- Total data volume. Under 100 gigabytes, use the default SQLite database and stop here. Over 100 gigabytes, a SQL Server connection is mandatory.
- Is the job over 1 terabyte? If so, LinkTek's over-1-terabyte note applies. Express formally satisfies it, but this is the size band where the performance warning bites hardest.
- File and link count. This, not raw volume, drives LinkFixer database size and therefore exposure to the Express 10 gigabyte cap. High file counts and dense cross-linking push the risk up sharply. Request a database sizing estimate from LinkTek before committing to Express on a high file count job.
- Number of processing servers. If more than one server must share a database, or the Inoculate process is in scope across servers, SQL Server is required. SQLite cannot do it.
- Migration window. Express underperforming is only a real problem if the window is tight. On a generous window, slower is survivable. On a fixed cutover date it is not, because a slow pass costs schedule on the critical path rather than merely costing time.
- Weigh the licence cost against the window. The saving from Express is a monthly licence figure multiplied by the number of months the machine runs. On a short migration that total is often small enough that it is not worth carrying the performance risk. Do this arithmetic explicitly rather than assuming the saving is large.
Illustrative example
The following is a worked illustration using rounded figures, to show how the sizing steps above resolve on a large job. It is not drawn from any particular engagement.
Take a migration of roughly two terabytes, spread across several hundred thousand files, running on an eight processor virtual machine to a fixed window of a few weeks.
| Factor | Value | Reading |
|---|---|---|
| Total data volume | Roughly 2 terabytes | About twenty times the SQLite ceiling, and above the 1 terabyte threshold. SQLite is definitively out. |
| File count | Several hundred thousand | High. This is what drives LinkFixer database growth, and therefore exposure to the Express 10 gigabyte cap. |
| Migration window | Fixed, a few weeks | Long enough to absorb some slowness, short enough that a slow or stalled pass costs schedule. |
| Virtual machine | 8 processors | Meets the consolidated article's minimum. An Express database engine could use only 4 of those cores. |
How it resolves. SQLite is excluded outright on volume. Express remains permitted, and LinkTek would call it functional, so there is no vendor grounds to rule it out. The case against it on this profile is the documented ceilings: a 1,410 megabyte buffer pool serving a link inventory of several hundred thousand files, half the machine's processors unavailable to the database engine, and an unquantifiable risk of hitting the 10 gigabyte database cap partway through. Against a fixed window, where a slow pass costs schedule rather than money, Standard is the safer specification wherever its licence cost is small relative to the overall job.
On a job with the same volume but a generous window, a lower file count, and real cost pressure, the same analysis can reasonably land on Express. That is the point. The vendor documentation does not decide this. The sizing does.
Summary table
| Option | Vendor position | Use when |
|---|---|---|
| SQLite, the default | Suitable for testing and small production jobs up to 100 gigabytes | Job under 100 gigabytes, single server, no Inoculate across servers |
| SQL Server Express | Permitted, named for jobs over 1 terabyte, "functional", but explicitly not recommended | Cost-constrained jobs with a generous window and a manageable file count, accepting the buffer pool, compute and 10 gigabyte ceilings |
| SQL Server Standard or above | What LinkTek point to for production installations | Large volume, high file count, tight window, multiple servers, or wherever the licence cost is small relative to the job |
Comments
0 comments
Please sign in to leave a comment.