Choosing a Firebird Server Architecture for Production

Problem Statement

When deploying Firebird 3.0+ in production, you must choose a server architecture that balances memory usage, concurrency, fault isolation, and scaling. Unlike Firebird 2.5, the three architectures are now unified into a single binary; the decision is a configuration change via ServerMode in firebird.conf. Selecting the wrong mode can lead to excessive memory consumption, poor latency under load, or unexpected crashes.

Decision Context

Key constraints that drive the architecture choice:

• Concurrent Connections – Number of simultaneous clients per database.
• Available RAM – Total memory for the Firebird process(es) and per‑connection caches.
• Fault Isolation Needs – Whether a single connection crash must not affect others.
• Database Count – One vs. many databases served by the same Firebird instance.
• Multi‑core Scaling – Requirement to utilize all CPU cores efficiently.

Architecture Comparison

Mode	Process Model	Cache Sharing	Fault Isolation	Memory Footprint	Scaling
SuperServer (Super)	Single process, threaded connections	Shared page cache per database	Low – a crash can affect all connections	Low – shared cache reduces per‑connection memory	Good for many connections to one database; limited per‑database SMP before 3.0
Classic	One process per connection	Private cache per connection	High – isolated crashes	High – memory per connection increases linearly	Scales across cores naturally; each process can use its own core
SuperClassic	Single process, threaded connections	Private cache per connection	High – isolated crashes	Intermediate – shared process but per‑connection cache	Better SMP than old SuperServer; still a single process

Trade‑Off Analysis

• Memory vs. Concurrency – Classic uses the most RAM but handles many concurrent connections without shared cache contention. SuperServer is memory‑efficient but may suffer if the shared cache becomes a bottleneck at high concurrency.
• Fault Isolation – Classic and SuperClassic provide strong isolation; SuperServer offers minimal isolation, which may be acceptable for tightly controlled environments.
• Scaling Across Cores – Classic scales naturally because each connection runs in its own process. SuperServer and SuperClassic rely on thread‑based concurrency; improvements in Firebird 3+ have made them more scalable than older SuperServer, but Classic still offers the most predictable core usage.
• Cache Tuning Complexity – In Classic/SuperClassic, DefaultDbCachePages applies per connection, making it easy to overshoot RAM if not monitored. In SuperServer, the same setting is shared, so a mis‑tuned value can affect all connections.
• Deployment Simplicity – A single process (SuperServer/SuperClassic) simplifies monitoring and backup; Classic requires per‑connection process management.

Concrete Implementation & Validation

1. Configure the Desired Mode

Locate firebird.conf (default /etc/firebird/3.0/firebird.conf on Linux). Add or modify:

# Set the server architecture
ServerMode = Super  # Options: Super, Classic, SuperClassic

Save the file and restart the Firebird service. On Linux:

sudo systemctl restart firebird-3.0.service

On Windows, use the Services console or:

net stop Firebird3
net start Firebird3

2. Verify the Mode Took Effect

Check the server log (e.g., /var/log/firebird/firebird.log) for a line similar to:

Server started in Super mode (SuperServer)

Alternatively, query the context variable:

SELECT RDB$GET_CONTEXT('SYSTEM', 'SERVER_MODE') FROM RDB$DATABASE;

Expected result: Super, Classic, or SuperClassic.

3. Load‑Test the Configuration

Use a representative workload: e.g., 100 concurrent clients performing SELECTs and occasional UPDATEs on the same database. Tools like wrk, pgbench‑style scripts, or a custom Python script with PyFirebird can simulate this.

During the test, monitor:

• Memory Usage – On Linux: ps -o pid,rss,cmd -p $(pgrep firebird); on Windows: Task Manager or Get-Process Firebird.
• CPU Utilization – top or sar.
• Query Latency – Record average round‑trip time.

Compare results across modes. For example, Classic may show ~200 MB per connection, whereas SuperServer may show ~40 MB total regardless of connections.

4. Validate Cache Behavior

Firebird exposes page buffer counts via monitoring tables. Run:

SELECT RDB$GET_CONTEXT('SYSTEM', 'CACHE_PAGES') FROM RDB$DATABASE;

In SuperServer, the value is shared; in Classic/SuperClassic it reflects per‑connection usage. Ensure the observed cache size matches your DefaultDbCachePages setting multiplied by the number of connections (for Classic/SuperClassic).

5. Adjust Tuning Parameters

After validation, tweak DefaultDbCachePages, DefaultDbCacheSize, and DefaultDbCachePages per connection as needed. Remember:

• In SuperServer: DefaultDbCachePages is shared across all connections to a database.
• In Classic/SuperClassic: the same value is applied per connection; adjust to avoid exhausting RAM.

Practical Checklist

1. Identify expected concurrent connections and available RAM.
2. Choose mode based on trade‑offs: memory vs. fault isolation.
3. Set ServerMode in firebird.conf.
4. Restart Firebird and confirm the mode.
5. Run a load test and record memory, CPU, and latency.
6. Tune cache settings; re‑test if necessary.
7. Deploy to production once the configuration meets performance and stability thresholds.

Limitations & Caveats

• Cache tuning behaves differently across modes; copying a configuration from Classic to SuperServer without adjustment can cause memory exhaustion.
• Firebird 3+ introduced SMP improvements, but legacy behavior may persist in older 3.x releases – always check the specific release notes.
• Changing ServerMode requires a full server restart; existing connections are dropped.
• Monitoring tools must be capable of distinguishing per‑connection metrics in Classic/SuperClassic.

Conclusion

Choosing the right Firebird server architecture is a configuration decision rather than an installation one. By evaluating concurrency, memory, fault isolation, and scaling needs, and then validating with a realistic workload, you can confidently deploy a mode that aligns with your production requirements.