PSFirebird is a PowerShell module focused on automating Firebird environments, databases, and common administrative workflows. The main goal is to make Firebird easier to script end-to-end without depending on a manual installer flow or a machine-specific setup.
The problem is trying to solve was simple: working with Firebird in automation often means mixing shell scripts, ad hoc local installs, version-specific quirks, and CI setup glue. That gets especially painful when you need to test multiple Firebird versions, rehearse upgrades, or spin up disposable databases for integration tests. PSFirebird is designed to reduce that friction.
What PSFirebird Does
Today the module can:
- Download official Firebird release assets and prepare portable environments
- Run multiple Firebird versions side by side
- Create, inspect, read, test, and remove databases
- Execute SQL through
isqlfrom PowerShell - Read and update
firebird.conf - Start ad hoc Firebird instances
- Register Firebird as a Windows service or Linux systemd service
- Backup and restore databases
- Convert databases across Firebird versions with streaming backup/restore
- Lock and unlock databases for filesystem-level copy using
nbackup - Parse
gstatoutput into structured PowerShell objects for tables and indices
The current codebase targets PowerShell 7.4+ on Windows and Linux. On Linux, the environment bootstrap currently targets Debian-based systems.
Why I Think This is Useful
PSFirebird is not meant to be another GUI admin tool. It is aimed at repeatable automation.
Some scenarios where it should be useful:
- CI/CD pipelines that need a Firebird server on demand
- Test matrices that need Firebird 3.x, 4.x, and 5.x side by side
- Upgrade rehearsals from older databases to newer engine versions
- Disposable local environments for development and debugging
- Scripting routine admin tasks instead of doing everything manually
One of the most useful parts for me is the ability to create isolated Firebird environments directly from PowerShell, then run the rest of the workflow against that environment in a predictable way.
This project builds on earlier work I’ve done across several Firebird community initiatives such as SqlAlchemy-Firebird, the Firebird .NET Provider, the Firebird ODBC Driver, and the Python driver. Across all of these efforts, maintaining a robust and consistently repeatable testing foundation has been essential.
Example
Here is a small example that prepares two Firebird versions and converts a database from one environment to another:
$tempPath = [System.IO.Path]::GetTempPath()
$fb3 = New-FirebirdEnvironment -Version '3.0.12' -Path (Join-Path $tempPath 'fb3')
$fb5 = New-FirebirdEnvironment -Version '5.0.3' -Path (Join-Path $tempPath 'fb5')
$sourcePath = Join-Path $tempPath 'legacy.fdb'
$targetPath = Join-Path $tempPath 'legacy.fb50.fdb'
$db = New-FirebirdDatabase -Database $sourcePath -Environment $fb3 -Force
$env:ISC_USER = 'SYSDBA'
$env:ISC_PASSWORD = 'masterkey'
Convert-FirebirdDatabase -SourceDatabase $db -SourceEnvironment $fb3 -TargetDatabase $targetPath -TargetEnvironment $fb5 -ForceThe module also includes helpers for scoped environment usage, configuration editing, SQL execution, service management, and database statistics collection.
Project Status
This is a real automation-oriented codebase, not just a thin proof of concept. The repository already includes:
- Unit tests
- Integration tests
- Cross-version conversion tests
- Windows and Linux CI coverage
- A GitHub Actions example showing end-to-end module usage in a workflow
Feedback Wanted
If you work with Firebird, I would especially like feedback on:
- Missing administrative workflows
- Cross-platform behavior and Linux packaging assumptions
- Upgrade and migration scenarios
- Command naming and module ergonomics
- CI and testing use cases
GitHub repository: https://github.com/fdcastel/PSFirebird
If this looks useful for your environment, take a look and let us know what would make it more practical for real-world Firebird automation.
