A slow database is rarely "Firebird". It is a query, an index, a long transaction, late maintenance, an old version or the environment. The right order is always: measure, find the bottleneck, fix it.
Six causes explain most cases — and each one calls for a different fix.
A full table scan is the number one cause of slowness — and usually the fastest one to fix.
Stale statistics or an inadequate index make the optimizer pick the worst path.
A forgotten transaction holds old record versions and degrades reads for every user.
A database piling up old record versions (late sweep) answers slower and slower.
Outdated versions miss fixes and lose optimizer gains on large databases.
Saturated disk, short memory, antivirus and backup running together with production.
Before "tuning" anything, you have to prove where the bottleneck is — with numbers, not guesses. That is what the diagnosis delivers.
The path Firebird chose for each painful query: index, join order, scan.
An index with old statistics delivers a bad plan — we measure and recalculate.
Who is holding the old versions: long transactions, forgotten connections and a late sweep.
Where the disk is actually consumed: data reads, indexes, backup and concurrency.
What your version delivers compared to the current one — and what the server can take.
None of these symptoms is fixed by restarting the server.
The questions that come up most in the daily life of those who depend on the database.
By measuring. Execution plans for the painful queries, open transactions and real disk usage. Without measuring, any change is a guess — and it usually hurts somewhere else.
It fixes it when the bottleneck is a table scan. An inadequate index — or too many indexes — also makes a database slow: it raises the write cost and can lead the optimizer to the worst path.
No. Sweep is maintenance, not a cure: running it constantly on a database full of long transactions just competes for disk with production. The path is finding what creates the garbage.
Only after you know where the bottleneck is. A large part of slowness comes from the database and the queries — and new hardware does not fix a bad query.
Then part of the gain may be in the version migration, not in tuning. They are two different paths: migration and performance.
Tell me the scenario: version, database size and when it freezes. I will say where the fastest gain is.
