advice for Firebird Hardware sizing

[Max]

Hello,

currently we are improving/refactoring our firebird database. As a result of our analysis, we have done several configuration changes which really helped improving the overall db performance. 

Because the Server now is a bit older and also the database outgrew the current hardware, we want to renew the Hardware on which the server is running. 

At the moment we are running Firebird 2.5 SuperClassic, but are planning to upgrade to 5.0. The server houses two Databases:

1. Database
   1. Size: 224G
   2. many accesses (200-300 simultaneously)
2. Database
   1. Size 9,2T 
   2. fewer accesses, but houses a lot of data as binary blobs which causes lots of i/O

From my research, i get that firebird relies heavily on I/O performance. Also Firebird 2.5 does not make a great job in multi threading, but it gets better when upgrading to 5.0.

So what i get from this is, that we would need a Server with a lot of ram to Cache the data. We should use the fastest SSDs we can find. Also a CPU with multithreading, but focus on a high single core performance would be good. Ideally with lots of L3 cache.

As you can probably guess, we are no firebird experts and sadly lack the expertise to properly work out how a decend sizing for our new hardware should look like, to be on the safe side for the next 5 years.

Have I overlooked any important aspects here? Because here are a lot of experienced experts i was wondering if you can help me with hardware sizing and suggest required specifications or even designated hardware?

Thank you very much in advance!

kind regards,

Max

[Dimitry Sibiryakov]

Max wrote 22.07.2025 13:08:
> Have I overlooked any important aspects here?

Yes, you missed the most important thing: each database is individual. What
is good for one will kill another. Therefore, scaling of equipment should be
carried out with constant monitoring of bottlenecks.
So your new server doesn't have to be perfect right out of the box. Think of
it as a base for further upgrading of individual components as needed.
I.e. the hardware must be volatile and scalable itself.

--
WBR, SD.

[Ashley Labuschagne]

Max hi there 

Just a point re hardware - never ever user RAID 5 (or 6) 
never ever!! 

       see      https://www.baarf.dk/BAARF/BAARF2.html 

Nothing, mirror, or RAID 10. 
RAID 10 pumps!! 

All the Best 
 -ashley 

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/497bcf83-21e7-4b45-9689-4cb3bcba8b9cn%40googlegroups.com.

[Dimitry Sibiryakov]

Ashley Labuschagne wrote 24.07.2025 14:12:
> Just a point re hardware - never ever user RAID 5 (or 6)
> never ever!!

Yes. Mindless usage of anything is a road to hell.

--
WBR, SD.

[Max]

Thank you so far for your answers! 

I get that every DB has its own requirements. 

Would it still be possible to make a general assessment of the correct hardware dimensioning? 

Are there any values or parameters I can provide from the database that might help?

kind regards,

Max

[Dimitry Sibiryakov]

Max wrote 24.07.2025 15:40:
> Would it still be possible to make a general assessment of the correct hardware
> dimensioning?

No.

BTW, despite common believes Firebird in most cases is CPU-bound, not disk-bound.

--
WBR, SD.

[Alexey Kovyazin]

Hello, 

The basic approach that you have described in the initial email is fine: fast disk, fast CPU, enough RAM to cache frequent parts of the database. 

If you budget is high, just buy the top available CPU with as many cores with 3.5+Ghz as possible, Raid10 with top NVMEs and 256+ Gb of RAM. Make sure to buy RAID controller with at least 8GTs.

If your budget is limited, better do some preparations. 

First, measure the performance of the existing hardware from Firebird point of view with Simple Insert Update Delete test:

https://ib-aid.com/en/simple-insert-update-delete-test-for-firebird/

It will give you baseline, which covers CPU and disk performance (but not memory). 

Then you should determine the profile of your system - i.e., is it a system with frequent fast queries or system with rather long analytical queries? 

Number of users does not matter much - 1 connection which serves as API gate can generate 10k queries per minute, or 10 users can idle for hours. 

What is necessary is the analysis of throughout on current system - i.e., queries, transactions, fetches, reads, writes per minute. The result of such analysis will be recommendation to buy more cores with less frequency or less cores with high frequency. 

Then, memory usage analysis of current system will hint how much memory you should buy. 

It will also influence the decision if  possible to economize on disks and purchase less fast but durable option. 

Consider to hire professional support, recommended by Firebird Foundation, to audit your specific situation - https://firebirdsql.org/ibsurgeon-firebird-configuration-optimization-audit-incident

Regards, 

Alexey Kovyazin 

 Max <kostho...@gmail.com>:

--

Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/96840124-74c1-4613-b309-f9ce2be8ec03n%40googlegroups.com.

[Max]

HI Alexey,

thank you very much for your detailed answer! That helps a lot.
I guess we will take the basic approach, but to be on the save side, we will also take a closer look at our performance data.

Regarding CPU, it seems like our current one is not the bottleneck:

 

Our transactions should mainly be pretty short. We have to reset the transaction counter once a year to avoid running into the limit. The limit of the counter is at 2^31 transactions. In the past 30 days, our transaction counter has grown 9.7% oft he total available numbers. On Average thats roughly about 6.943.530 transactions per day. 

 

Regarding i/o this is the the utilization over a 24 hour time frame:

Recently we have upgraded our memory from 32G to 128G. This erased some issues we’ve had in the past, but i’m not sure if 128G is sufficient for a future system. In the chart below, we can see that the firebird process itself consumes rather less memory. The most memory usage comes from cache/buffer.

Again, thank you very much for your detailed answer. I think that helps us a lot to determine the correct hardware measurements.

kind regards,

Max

[liviuslivius]

Hi

"

We have to reset the transaction counter once a year to avoid running into the limit. The limit of the counter is at 2^31 transactions. In the past 30 days, our transaction counter has grown 9.7% oft he total available numbers

"

If you move to FB3 or above, there is no limit here.

Regards,

Karol Bieniaszewski

[Mark Rotteveel]

There is still a limit, it is just a lot higher: 2^48 instead of ~2^31 - 1,

Mark
--
Mark Rotteveel

[Attila Molnár]

Your Firebird client must support 64bit TxID. It's not enugh just switch the database to FB 3+ to get the extened TxID.

[Mark Rotteveel]

On 29/07/2025 10:02, Attila Molnár wrote:
> Your Firebird client must support 64bit TxID. It's not enugh just switch
> the database to FB 3+ to get the extened TxID.

That is not correct. The client normally only gets a transaction handle
(in the range [1-65000]). The only problem you might have is if you use
an info request to obtain the transaction id (isc_info_tra_id) of the
handle, but that in itself doesn't limit the _range_ of the transaction
id, just your ability to get it (or, correctly parse the returned value).

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 29.07.2025 10:07:
> The only problem you might have is if you use an info request to obtain the
> transaction id (isc_info_tra_id) of the handle, but that in itself doesn't limit
> the _range_ of the transaction id, just your ability to get it (or, correctly
> parse the returned value).

...and Firebird client itself doesn't parse returned information buffer, it
is up to user application which must use isc_portable_integer() instead of
isc_vax_integer() as recommended starting from Firebird 1.0.

--
WBR, SD.

[Alexey Kovyazin]

Hello,

Current configuration looks like overprovisioned, are you sure you need upgrade?

 Regards, 

Alexey 

 Max <kostho...@gmail.com>:

To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/ad7e09e6-7fd7-4957-81b8-dedae8d92134n%40googlegroups.com.

[Max]

Hi Alexey,

we had big problems with the stability and performance of the database. Due to our analysis we found out that we do have a lot of very bad queries and cascading triggers which we are currently optimizing. But what really stablelized the db and made it performant again, was to install more RAM (before we went OOM on a regular basis) and also to optimize the firebird.conf. Since then, we had a lot of positiv reviews from our developers and users. Also the database haven't had a single breakdown.

The main reason we want to renew the hardware, was because out current hardware is about 6 years old and does not have any vendor or manufacturer support anymore.

For that reason we are trying to reevaluate the specifications for new hardware. 

I guess we will take a look into the suggested analysis from the service provider you mentioned above.

Again, thank you very much.

kind regards,

Max