In 2026, two families of tools coexist for interacting with a database. On one side, desktop clients installed on the developer's machine: DBeaver, DataGrip, TablePlus, Beekeeper Studio, QoreDB. On the other, hosted SaaS surfaces: Retool, Mode, Hex, Metabase Cloud, PopSQL. The two families look alike on the surface, since they all display tables and all run queries, but they don't solve the same problem.
The choice between local-first and cloud is not an aesthetic preference. It has concrete consequences for latency, for credential sovereignty, for how the tool fits into an existing infrastructure, and for what becomes easy or hard day to day. This article describes each model in its technical details and indicates in which contexts one or the other is the right choice.
What a Local-First Client Technically Involves
A local-first client is a native binary that runs on the user's machine. Connection credentials are stored locally, generally in the OS keychain or in an application-level encrypted vault. When the user runs a query, the connection goes directly from the machine to the database, without passing through an intermediary service. The application state (open tabs, history, saved queries, snippets) also lives on the local disk.
This definition implies a few concrete properties. A user account with the client's vendor is optional, or even nonexistent: DBeaver and DataGrip work without signing up, QoreDB too. The software's vendor has no backend that sees the queries or the results. If the database is in a private VPC reachable via VPN, the client works as soon as the VPN is up, with no additional configuration. The tool is usable offline for everything that doesn't require the database (reading history, editing a snippet, navigating an export).
What a Cloud-Based Database Tool Aims For
A cloud tool like Retool, Mode or Hex is a web application hosted by the provider. The user connects to it with an account, configures a data source by entering their database credentials, then works in an interface accessible from any browser. The service stores the credentials server-side, in a vault that belongs to the provider. When a query is executed, it's the service's backend that opens the connection to the database, runs the SQL, and returns the results to the user's browser.
This model is designed for sharing. The URL of a dashboard or a notebook can be sent to a colleague, who will open it without installing anything. Access rights are centralized. Automated workflows (scheduled reports, alerts, integrations) are handled by the platform. The cloud tool is typically used for cases where several people consume the same data, sometimes without having the rights or the technical skills to query it themselves.
Latency and Network Path
On a local-first client, the query makes a single round trip: user machine to database, then database to machine. The perceived latency depends solely on the quality of the link between the developer and their database. On a Postgres hosted in the same region as the machine, we're talking a few milliseconds for simple queries, which makes interactive exploration very comfortable.
On a cloud client, the query makes two hops: browser to SaaS service, then SaaS service to database. The latency adds up two network trips, which becomes noticeable when the user, the SaaS, and the database are not in the same region. For dashboards that refresh every hour, it doesn't matter. For exploration or debugging, where you chain ten short queries in two minutes, the difference is felt.
Credential Sovereignty and the Path of Data
In a local-first model, the database credentials never leave the user's machine. It's the user, and the user alone, who holds the password or the connection certificate. No third party can technically use them. The query results don't pass through an external service either: they go from the database to the machine's memory, period.
In a cloud model, the SaaS vendor technically has access to the credentials it stores (encrypted at rest, but decrypted at execution) and to the queries it runs. It's an operational reality openly acknowledged by serious providers, who publish audits, SOC 2 certifications, and detailed threat models. The question is not whether the provider is honest, it's whether the organization can accept this additional attack surface. For a team handling data subject to GDPR, HIPAA, or sovereignty constraints, the calculation is not neutral.
Access to Databases in a Private VPC
A significant share of production databases in 2026 live in a private VPC, without a public IP, reachable only from a bastion or through a corporate VPN. A local-first client adapts naturally: if the machine is on the VPN, it reaches the database, otherwise it doesn't. No infrastructure-side configuration to do for the tool itself. QoreDB additionally supports native SSH tunneling, which lets you reach a database behind a bastion without setting up the tunnel by hand.
A cloud tool, on the other hand, has to reach the database from its own servers. This requires either opening a hole in the firewall and allowlisting the provider's IPs, or installing a connector (Retool offers an on-premise agent, Hex a workspace connector) that maintains a reverse tunnel from the company's network to the SaaS. The second case works but adds a dependency on a third-party component that must be deployed, monitored, and kept up to date.
Where the Cloud Model Is the Right Choice
The cloud becomes relevant as soon as the primary value is sharing. A dashboard that ten people open every morning, a saved query that support consults on demand, an analysis notebook shared between data analysts and product managers: all of this is better served by Mode, Hex, or Metabase than by a desktop client. The browser, the shareable URL, and centralized authentication are the real strengths of these products.
Retool occupies a slightly different slot: it's less a database client than an internal-application builder, where the database is one data source among others. The typical use is to build an admin interface that support or ops use daily. Conversely, a desktop client isn't suited to this need: you don't install DBeaver for the entire support team.
Where the Local-First Model Remains the Right Choice
For the daily work of a product or backend developer, local-first remains the best format. Exploring a schema, debugging a slow query, checking a migration, writing a complex SQL script: these tasks are individual, interactive, latency-sensitive, and often touch sensitive databases. A local client covers this need without asking the organization to add a third-party service to its perimeter.
Local-first is also the natural format for tech teams that want to control where credentials live. Storing production passwords only in individual OS keychains, rather than in a shared SaaS vault, simplifies the threat model. If a developer leaves the company, you just rotate their rights in the database and reclaim their machine: there are no credentials persisted elsewhere.
For databases in a regulated environment (healthcare, finance, public sector), local-first avoids having to audit an additional SaaS provider. The tool runs on an already-compliant machine, uses already-managed credentials, and adds no new jurisdiction to the path the data travels.
Choosing Based on Actual Usage
In practice, the choice is made by use case, not by dogma. A team of five developers working with PostgreSQL and MongoDB daily will be well served by a local-first client like DataGrip, DBeaver, or QoreDB. A data team producing dashboards consumed by thirty people will be well served by Mode, Hex, or Metabase. A startup that wants an admin interface for its support will use Retool. A solo developer who just wants to write queries will want a fast local client that opens in two seconds.
Many organizations use both in parallel, and that's the healthiest scenario. Developers work in their local-first client for code and debugging. Dashboards and internal tools live in a cloud platform dedicated to that need. Looking for a single tool that covers both uses generally leads to a compromise that satisfies no one.
QoreDB's Defining Choice
QoreDB is explicitly positioned in the local-first family. The runtime is Tauri 2, the backend is in Rust, and the drivers (PostgreSQL, MySQL, MongoDB, SQLite, SQL Server, CockroachDB) are native and run inside the machine's binary. Credentials are stored in an Argon2-encrypted vault, locally. No QoreDB account is required to use the application: no backend that sees the queries, no mandatory telemetry. Cross-database federation, when used, relies on DuckDB embedded in the binary and executes the join on the machine.
This choice comes from a conviction about the target audience: QoreDB is aimed at the product developer, the small tech team, the backend engineer who touches PostgreSQL or MongoDB several times a day. For this profile, latency, credential sovereignty, and access to databases in a private VPC weigh more than dashboard sharing. The desktop format is aligned with this need. For sharing and BI uses, other families of tools exist and do the job better: it's healthier to have two families than one compromise.
Local-first and cloud are not in head-on competition; they are two answers to two different problems. The first optimizes for individual work on sensitive databases, with minimal latency and maximal sovereignty. The second optimizes for large-scale sharing, automation, and accessibility from a browser. Choosing the right model in 2026 means, above all, knowing which of the two problems you're trying to solve.
Stay updated on new releases
Subscribe to get product releases, new drivers notifications, and technical tutorials.