Context

We inherited a legacy project. The database was SQL Server, the reporting layer was SQL Server Reporting Services (SSRS), and the project budget was comparatively limited. Our task: migrate the database to PostgreSQL and find a workable replacement for a handful of SSRS reports — mostly pivot tables over four data marts, with drilldown capability — serving a small group of internal business users.

This post reflects on the choices we made, the ones we didn’t, and what we learned along the way.

The Landscape: Why SSRS Replacement Is Non-Trivial

SSRS has always been an acquired taste. It is not particularly friendly to business users, self-service analytics is not its strength, and its architecture is firmly rooted in the Microsoft ecosystem. But it does one thing very well: pixel-perfect, parameterised, paginated reports — including pivot tables with hierarchical drilldown that most modern BI tools struggle to replicate cleanly.

When you leave that ecosystem, you quickly discover that “replace SSRS” is not a single well-defined problem. It depends entirely on what you were actually using it for.

For organisations staying within the Microsoft world, the natural path is Power BI Report Server (PBIRS) — the on-premise successor that Microsoft now ships in place of SSRS, which was notably absent from SQL Server 2025. PBIRS supports the same RDL report format as SSRS, meaning many existing reports can be migrated without a complete rewrite. For cloud-first teams, Power BI paginated reports in the Power BI Service is the equivalent cloud-native path.

However, once you have moved to PostgreSQL, Power BI becomes considerably less straightforward. PostgreSQL is not a natively supported embedded data source for Power BI paginated reports — only Azure SQL Database and Azure Synapse Analytics are supported out of the box. Connecting to Postgres requires routing through ODBC or a data gateway, and that gateway only runs on Windows — not in a container, requiring a dedicated Windows server or VM. For a team that has just moved away from the Microsoft stack, this is a significant and often underdiscussed friction point. Additionally, Power BI Pro pricing increased 40% in April 2025, which is relevant context for any long-term cost assessment.

Other commonly mentioned alternatives include Pentaho (with a long history in the data warehouse space but a complicated open-source/enterprise split), Jaspersoft, and Bold Reports (which supports RDL import). For teams building from scratch on open-source tooling, Apache Superset and Metabase are the most actively maintained options.

The Architectural Opportunity: Introducing a Proper OLTP/OLAP Split

Our predecessors had not separated operational and analytical concerns. Everything lived together in SQL Server. The migration to PostgreSQL gave us a natural opportunity to fix this — and we took it.

We introduced dbt (data build tool) as the transformation layer between the operational database and the reporting marts. This was not a deeply deliberated decision at the time — dbt was an obvious choice given the team’s familiarity — but it proved sound. The four data marts that feed the reports are now explicitly modelled, versioned, and tested as dbt models, rather than being implicit artefacts of ad-hoc queries.

One honest note: SQLMesh has emerged as a compelling alternative to dbt, with stronger support for incremental models and a different philosophy around state management. We would want to evaluate it seriously on future projects, though dbt continues to serve us well here.

The result of this separation is that the reporting layer now queries clean, purpose-built marts rather than the operational tables directly. This is the right architecture regardless of which reporting tool sits on top.

Finding a Reporting Tool: The Pivot Table Problem

The central requirement was pivot table support with drilldown. This rules out a large portion of the BI tool landscape, or at least makes it uncomfortable.

Apache Superset has a Pivot Table V2 that supports row/column grouping and metric aggregation. However, it has real gaps: collapsible hierarchical drilldown — the expand/collapse behaviour familiar from Excel and SSRS — was still being requested by users in 2024 with no native solution, and pivot table Excel export only landed in July 2025. Superset is a powerful and actively developed platform, but its pivot story was clearly less mature at the time of our evaluation.

Metabase has stronger pivot table support and a more polished user experience for non-technical users. We ran a short evaluation — a day or two — but did not reach a firm conclusion in that time. Metabase remains a serious contender and is our identified upgrade path if requirements grow.

Rill (rilldata.com) was the other platform we evaluated seriously. It is a younger and more opinionated tool, built around fast operational dashboards and exploratory analytics, with a developer-first workflow that uses YAML and SQL configuration files rather than a GUI. We had prior positive experience using dbt and Rill together on an R&D project, which informed our confidence here.

How We Validated the Decision: Two Unconventional Methods

Faced with cost pressure and no external guidance, we needed a pragmatic way to validate our tooling choice without spending weeks on formal evaluation. We used two complementary approaches.

1. Codebase size as a cognitive load proxy

We used scc — a fast, accurate code counter — to compare the size of the Metabase, Superset, and Rill codebases. The reasoning: a smaller, more focused codebase means a shorter path to understanding the tool, debugging unexpected behaviour, and contributing fixes. For a team without a dedicated BI engineer and with a depleted budget, this is arguably more operationally relevant than a feature matrix.

Rill is significantly smaller and more focused than either Metabase or Superset, which are both large, general-purpose platforms.

2. Attempting to fix a real bug

We went further than reading the code — we attempted to fix an actual open Rill issue. This approach tells you things no feature comparison can: How approachable is the codebase? How does the team respond to outside contributors? What is the actual code quality day-to-day?

This kind of due diligence is almost never mentioned in migration write-ups, but it is one of the most honest signals available for evaluating an open-source dependency.

What We Learned About Rill — Including the Caveats

Our evaluation surfaced a few things worth noting for anyone considering Rill:

• Agentic coding in production: Parts of the Rill codebase appear to involve AI-assisted development. This is new and relatively uncharted territory for an open-source project, and raises questions about long-term code consistency and maintainability.
• Distributed development: Development work appears to be partially distributed internationally. Not a disqualifying factor, but relevant context when assessing contributor dynamics and response times.
• No on-premise enterprise offering: Rill’s hosted, multi-user product is cloud-only. For customers with GDPR constraints, data residency requirements, or simply a reluctance to place business-critical data in a third-party cloud, this is a potential hard blocker.

The third point is the most significant for our situation. Our customer would likely be uncomfortable with a cloud-only reporting solution for sensitive business data.

Our Decision: rill developer, On-Premise

The resolution is pragmatic: we are deploying rill developer — Rill’s local, single-user mode — on-premise, without IAM. This sidesteps the cloud dependency entirely for now. The business user gets a working, capable reporting environment. The team gets a tool with a manageable codebase and a developer-friendly workflow.

We have explicitly scoped any future requirement for multi-user access, SSO, or enterprise permissions as a change request for the customer to fund. At that point, Metabase becomes the most natural upgrade path — it is a more mature platform for multi-user deployments and has the pivot table capability our customer needs.

This is not a perfect solution. It is a well-reasoned, honest one.

Summary

The broader lesson: “replace SSRS” is not a product decision — it is an architectural decision. The reporting tool is the last piece. Getting the data layer right first (OLTP/OLAP separation, clean marts, dbt) means the reporting tool can be swapped without rebuilding the foundation.

Prior work using dbt and Rill for R&D analysis is documented here.

I recently spent some time trying to get a sense of two open source e-invoicing libraries — mustangproject (Java) and ZUGFeRD-csharp (.NET) — and came away with more questions than answers, but also some useful perspective. This post summarises what I found. I am not a domain expert in e-invoicing standards, so please treat the observations here with appropriate caution and verify anything that matters to your situation.

Measuring Code Size: scc and the COCOMO Trap

A natural starting point is asking “how big is this project?” A useful free tool for this is scc (Sloc, Cloc and Code), a fast Go-based line counter that also computes cyclomatic complexity and COCOMO cost estimates per language. It is in many ways the spiritual successor to David A. Wheeler’s sloccount.

Running scc on both libraries reveals an immediate problem: the raw totals are dominated by XML, XSD, and XSLT files, not handwritten application logic. For mustangproject the Extensible Stylesheet (XSL) category alone accounts for roughly 688,000 lines; for ZUGFeRD-csharp the XML category runs to around 753,000 lines. Both of these are largely normative artefacts from standards bodies — XSLT stylesheets and Schematron rules from KoSIT and FeRD, not original code.

When you filter to just the handwritten logic the picture becomes more comparable:

Two libraries implementing roughly equivalent functionality, at almost identical size — but the Java is nearly twice as complex per line. Whether that reflects Java’s more verbose OOP patterns or accumulated conditional handling over a longer project lifetime is hard to say without deeper analysis.

On COCOMO estimates

scc produces COCOMO “organic” cost and schedule estimates. For mustangproject it produced a figure in the tens of millions of dollars. This is not meaningful here. The COCOMO model was calibrated on large 1980s-era institutional projects with significant process overhead. It has no concept of “this file was transcribed from a normative standards document.” The relative complexity ratios within COCOMO (more branching → more effort) are still roughly valid as trends, but the absolute dollar figures should be ignored unless you are specifically modelling labour costs in a comparable institutional context.

The honest conclusion is that scc is useful for getting a rough sense of where the mass of a project lives — how much is handwritten logic versus bundled artefacts, which language carries the complexity — but effort estimation from static metrics alone is essentially hopeless for projects of this kind. The moment a codebase bundles normative standards documents, the numbers stop reflecting developer effort in any meaningful way.

The KoSIT Test Suite: A Genuine Quality Signal

A more useful quality indicator than line counts is test coverage against normative reference cases. For XRechnung, KoSIT maintains an official test suite of real-world business case invoices and technical edge cases, versioned alongside each XRechnung release. This is a government-mandated artefact — KoSIT operates on behalf of the IT-Planungsrat, the joint federal-state IT standards body.

The ~1,200 XML files found in the ZUGFeRD-csharp repository are almost certainly these KoSIT test instances, bundled as integration tests. That is a good sign — it means the library is testing its output against the normative reference. However, it also means those files should be entirely excluded from any LOC or effort analysis.

For ZUGFeRD there is no equivalent official test suite. The closest thing is the ZUGFeRD/corpus repository, which is maintained by the Mustang team rather than FeRD, and is explicitly described in its own README as unofficial and makeshift. This asymmetry reflects the different governance structures: KoSIT has a legal mandate and publishes rigorous versioned artefacts; FeRD is an industry forum with no equivalent obligation.

ZUGFeRD and XRechnung: Not Synonyms

It is easy to treat these two terms as interchangeable, but they are architecturally quite different things built on the same foundation.

Both are implementations of the European standard EN 16931, which defines a semantic invoice data model. On top of that:

• XRechnung is a pure XML file — a German CIUS (Core Invoice Usage Specification) that tightens EN 16931 for public sector use, notably requiring a Leitweg-ID for routing to the correct government inbox. It has no visual component. It is governed by KoSIT on behalf of the IT-Planungsrat.

• ZUGFeRD is a hybrid format: a PDF/A-3 file with an invoice XML embedded as an attachment. A human can read it in any PDF viewer; the embedded XML can also be extracted and processed automatically. It was designed primarily for B2B use. It is governed by FeRD (Forum elektronische Rechnung Deutschland).

They overlap because ZUGFeRD 2.1.1 introduced a dedicated XRechnung reference profile, meaning a ZUGFeRD envelope can carry XRechnung-compliant XML. But they remain distinct standards with distinct governance bodies.

The legal timeline

The obligations created by these standards are real and time-bound:

• B2G (suppliers to federal government): mandatory since 27 November 2020 at federal level; most Bundesländer have since followed.
• B2B receiving: mandatory since 1 January 2025 under §14 UStG (Wachstumschancengesetz) — every German B2B company must be able to process EN 16931-compliant e-invoices.
• B2B sending: mandatory from 1 January 2027 (with transitional rules).

There is no KoSIT certification scheme for software vendors. Conformance is defined operationally: if your output passes the KoSIT validator, it is conformant. Invoices that fail the validator are automatically rejected by government portals, which is a stronger forcing function than any formal certification could be.

The Libraries: Mustangproject vs ZUGFeRD-csharp

mustangproject

mustangproject is a Java library, Maven artifact, command-line tool, and REST server. It has been in development since the early days of ZUGFeRD and has accumulated broad format support: ZUGFeRD 1 and 2.x, Factur-X, and XRechnung (CII and UBL syntaxes).

A key architectural decision is that validation is built in. The library bundles the KoSIT XRechnung Schematron rules directly (as listed in its NOTICE file), as well as EN 16931 validation artefacts from the CEN. This makes mustangproject the de facto reference implementation for validation in the German e-invoicing open source ecosystem.

The project’s popularity in the Java ecosystem is partly structural: Java has a long history in German ERP and accounting software (SAP, Lexware, Sage), so a library with a clean Maven dependency fits naturally into existing stacks. The command-line tool also broadened the audience beyond Java developers.

One caveat worth noting: an open bug shows a case where mustangproject rejects XML that the KoSIT validator accepts — meaning it applies stricter rules than the official reference in some edge cases. This may or may not be a problem depending on your use case.

ZUGFeRD-csharp

ZUGFeRD-csharp started in 2013 as a hobby project and grew to be used by hundreds of companies. It remains the primary .NET option for this domain.

However, it has recently undergone a significant licensing change. Starting with version 18.0.0, the project moves to an open-core model: the base library remains open source for stability and bug fixes, but new features and — notably — validation are now part of the commercial FactoorSharp product.

The commercial validation component is advertised as using Mustang, Valitool, and VeraPDF as backends. This is worth noting for two reasons:

1. It means the .NET ecosystem’s primary validation path delegates to the Java library — Mustang again acting as the ground truth.
2. From a purely commercial perspective, advertising that your paid feature calls a free competitor may not be the strongest value proposition, though the integration work and convenience still has value.

For teams currently using ZUGFeRD-csharp, version 18 remains available as open source, but future XRechnung version support and new features will likely appear first or only in the commercial tier. This is a risk worth factoring into dependency decisions.

Why .NET Validation Delegates to Java: The XSLT 2.0 Gap

The decision to call Mustang from the commercial .NET validation tier is not arbitrary — it reflects a structural platform limitation that is worth understanding.

The KoSIT Schematron validation rules are compiled to XSLT 2.0. The built-in .NET XML stack (XslCompiledTransform) only supports XSLT 1.0. As one developer put it plainly in the ZUGFeRD-csharp issue tracker, document-uri() — an XSLT 2.0 function used in the KoSIT stylesheets — is simply not recognised, making native .NET validation impossible without an external processor.

The natural solution is Saxon-HE, the open source XSLT 3.0 processor from Saxonica, available as a NuGet package. However, here the platform fragmentation becomes painful:

• Saxon-HE for .NET Framework works and has been demonstrated in community contributions to ZUGFeRD-csharp, but ZUGFeRD-csharp targets .NET Standard, not .NET Framework.
• SaxonCS — the modern .NET Standard/Core-compatible version — is a commercial product, not open source, and was described in the ZUGFeRD-csharp community as unaffordably expensive for an open source library dependency.

This is corroborated by our own experiments, which reached the same conclusion independently.

The net result is a somewhat uncomfortable situation for the .NET e-invoicing ecosystem: the only practical path to free, standards-compliant XRechnung validation on modern .NET is to shell out to a Java process running Mustang — which is exactly what the commercial FactoorSharp tier does. There is also concern in the community that Saxonica’s near-monopoly on XSLT 2.0/3.0 processing creates a long-term open source risk, since the Java ecosystem’s Saxon-HE (also MPL-2.0) could in principle face the same commercial pressure at any time.

For Java, this problem does not arise: Saxon-HE on the JVM is fully open source, supports XSLT 3.0, and integrates cleanly — which is one more structural reason why mustangproject can offer validation as a first-class feature while ZUGFeRD-csharp cannot, at least not without commercial dependencies.

Three Ironies — and a Hidden Fourth

Stepping back, the landscape described in this post contains a set of structural ironies that are worth naming explicitly, because together they explain a lot about why the ecosystem looks the way it does.

The first irony is commercial: ZUGFeRD-csharp’s paid validation tier advertises that it calls Mustang — a free Java competitor — as one of its backends. Whatever the integration value, announcing this publicly tells potential customers that the core capability is available for free elsewhere.

The second irony is a platform one: .NET, the ecosystem being used to implement a legally mandatory invoicing standard, natively supports only XSLT 1.0 — while the KoSIT validation rules that define conformance with that standard are written in XSLT 2.0. The platform and the standard passed each other in opposite directions, and nobody built the bridge. The result is that the .NET library’s commercial validation tier ends up shelling out to a Java process, which is the one mainstream platform where the bridge was in fact built.

The third irony is a browser one. Chrome has officially deprecated XSLT, with removal from stable releases planned for November 2026 — and Firefox and WebKit have indicated plans to follow. The stated reason is security: libxslt was unmaintained for roughly six months of 2025, and as an aging C codebase it represents a potent attack surface for a feature that is now rarely used on the web. The XSLT stylesheets bundled in both libraries for generating human-readable HTML invoice views will stop working in browsers that do this rendering client-side. To be clear, this does not affect server-side validation or rendering pipelines — mustangproject, the KoSIT validator, and any server-side workflow are unaffected. But it is a reminder that the browser ecosystem, which never advanced beyond XSLT 1.0 either, is now actively retreating even from that.

The hidden fourth irony underlies all three. XSLT 2.0 was published as a W3C recommendation in 2007. The broader platform ecosystem — browsers, .NET, and others — largely chose not to implement it. The standards bodies building XRechnung validation on XSLT 2.0 Schematron were making a reasonable technical bet on a published W3C standard; the platform world had quietly decided not to honour it. Saxonica filled the gap and now holds something close to a monopoly on XSLT 2.0/3.0 processing, with all the open source sustainability risk that entails. Java happens to be the platform where Saxonica’s open source tier works cleanly — and so mustangproject, almost incidentally, ended up on the right side of a technology adoption decision made twenty years ago by people who were thinking about something else entirely.

Summary

Corrections and additions welcome. This post reflects a learning process rather than expert knowledge, and the e-invoicing standards landscape changes at least once a year with each KoSIT release cycle.

Harder than it should be, it turns out — but not for the reasons you’d expect.

Starting point

Fresh Windows install, Ruby 4.0.3 via winget, following the official GitHub Pages documentation. Step one: create a new Jekyll site, add the github-pages gem, run bundle install. Straightforward enough.

Except it isn’t.

The version wall

bundle install fails immediately with a dependency error: commonmarker, somewhere deep in the github-pages gem chain, explicitly requires Ruby >= 2.6, < 4.0. Ruby 4.0.3 is, technically, not less than 4.0.

The GitHub documentation points you to pages.github.com/versions.json for the current gem version but says nothing about Ruby version requirements. To be fair, pinning documentation to fast-moving version constraints is genuinely hard — but a note like “Ruby 3.x recommended” would save a lot of people some time.

The fix: uninstall Ruby 4.0.3, install 3.4.x via RubyInstaller (with Devkit — don’t skip that), start over.

99 gems

Once the right Ruby is in place, bundle install completes cheerfully:

Bundle complete! 7 Gemfile dependencies, 99 gems installed.

99 gems. For a static site generator. If you know the song, you know the song.

To be fair to Jekyll: the resulting site looks genuinely nice out of the box, Minima is a clean default theme, and the whole thing is now running on localhost exactly as advertised. The friction was entirely in getting there.

What I’d do differently

Install Ruby via RubyInstaller from the start, not winget. Pick 3.3.x or 3.4.x. Run ridk install when it asks you to. Then follow the docs.

Two hours of dependency archaeology, condensed into one paragraph.