In the left menu you will find the detailed documentation divided the following sections:

Release Notes — each Firebird release is accompanied by a ′Release Notes′ document, which contains the description of new features and fixed bugs. In this section, you will find all release notes.
Reference Manuals — this section contains Quick Start guides for new users and various guides devoted to specific topics.
White Papers & Presentations — in this section there are numerous white papers and presentations regarding Firebird-related topics. In this section, you can also find Firebird presentations from various conferences around the world.
FAQ — a collection of community FAQ links in English, Russian, Portuguese and another language.
Firebird Books — descriptions and links for purchasing several books devoted to Firebird.
Drivers Documentation — this section contains documents and links to documentations for Firebird drivers.
Third-Party Docs and Articles — a collection of various articles devoted to Firebird.

Summary of New Features
Firebird 5.0 introduces many improvements without any changes in architecture or operation, the most important are:

Parallel (multi-threaded) operation for backup/restore, sweep and index creation;

Partial indices;

SKIP LOCKED clause for WITH LOCK, and statements;

Inline minor ODS upgrade;

Compiled statement cache;

PSQL and SQL profiler;

Support for WHEN NOT MATCHED BY SOURCE for MERGE statement;

Support multiple rows for DML RETURNING;

New built-in functions and packages;

Denser record-level compression;

Network support for scrollable cursors;

The following list summarises the features and changes, with links to the chapters and topics where more detailed information can be found.

Support for parallel operations Vlad Khorsun Tracker ticket: #7447 The Firebird engine can now ute some tasks using multiple threads in parallel. Currently, parallel ution is implemented for the sweep and the index creation tasks. Parallel ution is supported for both automatic and manual sweep. To handle a task with multiple threads, the engine runs additional worker threads and s internal worker attachments. By default, parallel ution is not enabled. There are two ways to enable parallelism in a user attachment: the number of parallel workers in DPB using new tag isc_dpb_parallel_workers, the default number of parallel workers using newting ParallelWorkers in firebird.conf. The gfix utility has a new command-line switch, -parallel, that allows to the number of parallel workers for the sweep task. For example, the following will run sweep on the given database and asks the engine to use 4 workers: gfix -sweep -parallel 4 gfix uses DPB tag isc_dpb_parallel_workers when attaches to , if switch -parallel is present. A similar option was also added to gbak. The new firebird.confting ParallelWorkerss the default number of parallel workers that can be used by any user attachment running parallelizable task. The default value is 1 and means no use of additional parallel workers. The value in the DPB has a higher priority than theting in firebird.conf. To control the number of additional workers that can be d by the engine, there are two newtings in firebird.conf: ParallelWorkerss the default number of parallel workers used by a user attachments. Can be overridden by attachment using tag isc_dpb_parallel_workers in DPB. MaxParallelWorkers Limits the maximum number of simultaneously used workers for the given database and Firebird process. Internal worker attachments are d and managed by the engine itself. The engine maintains per-database pools of worker attachments. The number of threads in each pool is limited by the value of the MaxParallelWorkersting. The pools are d by each Firebird process independently. In SuperServer architecture worker attachments are implemented as light-weight attachments, while in Classic and SuperClassic they look like usual user attachments. All worker attachments are embedded the creating server process. Thus, in Classic architectures there are no additional server processes. Worker attachments are present in monitoring tables. Idle worker attachments are destroyed after 60 seconds of inactivity. Also, in Classic architectures, worker attachments are destroyed immediately after the last user connection detaches from the database. Examples: in firebird.conf ParallelWorkers = 4, MaxParallelWorkers = 8 and restart Firebird server. Connect to test database not using isc_dpb_parallel_workers in DPB and ute a INDEX …​ SQL statement. On , the index will be d and the engine will use three additional worker attachments. In total, four attachments in four threads will work on index creation. Ensure auto-sweep is enabled for test database. When auto-sweep runs on that database, it will also use three additional workers (and run within four threads). More than one task at a time can be parallelized: make two attachments and ute a INDEX …​ in each of them (of course indices to be built should be different). Each index will be d using four attachments (one user and three worker) and four threads. Run gfix -sweep without specifying switch -parallel: sweep will run using four attachments in four threads. Run gfix -sweep -parallel 2 : sweep will run using two attachments in two threads. This shows that value in DPB tag isc_dpb_parallel_workers overrides value ofting ParallelWorkers.