Open source or proprietary: which database client to favor

Choosing a database client also means choosing a licensing model. The decision is rarely made at that level, but it shapes everything else: who can read the code, who can fork it, who pays, who decides the roadmap, and what happens the day the vendor disappears. Three broad models coexist today: pure open source, closed proprietary, and open core. Each answers a different use case.

This article compares the three approaches on the criteria that matter over time: code auditability, project longevity, quality of support, and total cost over several years. The goal isn't to crown a winner, but to give you the keys to decide with full awareness of the trade-offs.

The pure open source model

The historical references are DBeaver Community Edition (Apache 2.0), pgAdmin (PostgreSQL License), phpMyAdmin (GPL-2.0) or MongoDB Compass (SSPL). All the code is public, modifiable, redistributable under the terms of the license. No one can cut off access, raise prices unilaterally or remove a feature overnight without a fork being possible.

The most concrete advantage is auditability. A security team can read the code, verify how credentials are stored, understand what goes out over the network, and audit the dependencies. For a database client that handles production secrets, this transparency is no small matter.

The second advantage is longevity. As long as an active community exists, the project outlives its original vendor. pgAdmin has been running for more than twenty years. DBeaver Community has spawned several forks. The code doesn't die with a startup.

The direct cost is zero. The indirect cost, however, is paid in time: you have to accept that the roadmap's priorities are driven by the maintainers (and their sponsors), that support happens through GitHub or Stack Overflow, and that the UX improves at the pace of contributions. Pure open source vendors that fund their work often sell services around it: training, enterprise support, managed hosting.

The closed proprietary model

On the proprietary side, the references are DataGrip (JetBrains), TablePlus, Navicat, Studio 3T or SQL Server Management Studio. The code is closed, and the vendor controls the entire chain: roadmap, pricing, distribution, support. The customer pays for a license (perpetual, annual or subscription) and receives in exchange a polished product and a direct support channel.

This model has two real strengths. The first is UX: when an entire team lives off the product, the polish accumulates. DataGrip and TablePlus are recognized for the quality of their interface, their consistency and their speed of iteration. The second is support: a ticket gets an answer, sometimes a fix, within a predictable window.

The trade-offs are structural. Auditability depends solely on what the vendor is willing to document. The cost grows with the team: 250 dollars per seat per year for DataGrip, 89 dollars for TablePlus perpetual but with limited updates. Over five years and twenty seats, the bill runs into the tens of thousands of euros. And if the vendor shuts down, is acquired or pivots, there's no plan B: the code isn't recoverable.

The most underestimated risk is format lock-in. A DataGrip or Navicat connections file isn't trivial to export to another client. The more configurations, saved queries and scripts the organization accumulates in the tool, the higher the cost of leaving.

The open core model

Open core is more recent and more nuanced. The heart of the product is published under an open license (Apache 2.0, MIT), while some advanced features are under a commercial or source-available license (often BUSL or the Elastic License). It's the model of Beekeeper Studio (Community under MIT, paid Ultimate Edition), DBeaver Pro (Community free, Pro proprietary), and that of QoreDB (Core under Apache 2.0, Premium modules under BUSL 1.1).

The idea is to combine both logics. The open foundation guarantees the auditability of the critical path: connection, query execution, credential storage, database drivers. A security team can read what it needs to read. The advanced modules (cross-database federation, time travel, data contracts, AI assistant in QoreDB's case) fund development and remain inspectable without being freely redistributable.

The point to watch is the boundary between Core and Premium. A clear, stable and documented boundary is reassuring: you know what you install for free and what you'll pay for later. A blurry or shifting boundary is a negative signal. At QoreDB, the Premium scope is listed explicitly in the repository's CLAUDE.md file, and every file carries its SPDX header: Apache-2.0 or BUSL-1.1. It's a deliberate editorial choice: no surprises, no bait-and-switch.

Four criteria to decide

Auditability. If a security policy requires reading the code that handles credentials and queries, closed proprietary is ruled out from the start. Pure open source answers this 100%. Open core answers it for its Core scope, which generally includes the sensitive functions. For QoreDB, that's the case: vault, drivers, query execution and SQL validation are all in the Apache 2.0 Core.

Longevity. Three questions to ask: who maintains the code, for how long, and what happens if the vendor disappears? An open source project active for ten years with several maintainers is more solid than a one-year-old proprietary startup. An open core whose Core can keep living as a fork is a real safety net.

Support. Pure open source has community support, free but unpredictable. Proprietary has contractual support, paid and guaranteed. Open core generally combines both: community support on the Core part, contractual support through the Premium license. If criticality is high and response time must be bounded, an SLA can be purchased.

Long-term price. Pure open source is free in licensing, costly in internal time. Proprietary is predictable year after year but grows with the team. Open core starts free and only becomes paid if the Premium modules are needed: a developer who uses only the Core functions pays nothing, while a team that wants multi-database federation or the AI assistant pays for those modules. The calculation is done over three to five years, not the current year.

Which model for which context

A solo developer working mostly with PostgreSQL and SQLite will be well served by pgAdmin or DBeaver Community: zero cost, readable code, a large community. A backend team that multiplies engines (PostgreSQL, MongoDB, Redis, SQL Server) and values speed of iteration will often prefer DataGrip or TablePlus: the cost is offset by the daily time savings.

An organization that needs both auditability of the critical path and advanced features (federation, visual diff, data contracts) will turn to an open core model: Beekeeper Ultimate, DBeaver Pro or QoreDB. The practical rule is to first check that the Core/Premium boundary is clear, that the Core's license is OSI-approved, and that the security-critical functions are indeed in the Core. In QoreDB's case, the Argon2 vault, native drivers, production protections and query execution are all under Apache 2.0: only the high business-value functions move to BUSL.

A regulated context (banking, healthcare, public sector) adds a layer: the license must be compatible with internal policy, internal redistribution must be allowed, and the supply chain must be verifiable. Apache 2.0 and MIT pass everywhere. Source-available licenses (BUSL, Elastic, SSPL) require a careful reading of the text, but generally allow internal use without friction.

QoreDB's choice

QoreDB was designed as open core from the very first commit. The Core (Apache 2.0) covers everything a developer needs to use the product day to day: connecting to the five drivers (PostgreSQL, MySQL, MongoDB, SQLite, SQL Server), SQL editor, data grid, encrypted vault, CSV/JSON/SQL/HTML exports, production protections, SSH tunnels. The Premium modules (BUSL 1.1) group the functions that fund the project: cross-database federation via DuckDB, time travel, data contracts, AI assistant, visual diff, Parquet and XLSX exports, advanced ER diagram.

The choice of the BUSL over a purely proprietary license is deliberate. The Premium code remains readable, auditable, and modifiable for non-competitive use. At the end of the change period (typically 4 years), each Premium version switches to Apache 2.0. It's a compromise that protects the business model without closing the code, and that makes any migration possible if the vendor disappears.

In summary

The choice between pure open source, proprietary and open core isn't made on the single criterion of initial price. It's made on the balance between auditability, longevity, support and cost spread over time. Pure open source maximizes freedom and minimizes direct cost, at the price of community support. Proprietary maximizes polish and support, at the price of complete dependence on the vendor. Open core seeks a middle ground: open code on the critical path, a viable business model on the added value. None is universally better. The right model is the one that answers your strongest constraint, whether budgetary, security-related or organizational.