What We Learned Building DBO Studio 1.1.0

We spent a surprising amount of time thinking about what should happen when you forget to add LIMIT to a query.

At first, it sounds like a small detail.

You write:

SELECT *
FROM users;

and expect to see some rows.

But what happens when users has a few million records?

A database client has to make a decision. Should it fetch everything? Should it warn you? Should it silently limit the result? Or should it simply let the database do what it was asked to do?

We decided that the safer default is to fetch a manageable amount of data and make the rest available through pagination.

That's one of the changes in DBO Studio 1.1.0.

It's also a good example of how this release came together. Most of the work wasn't about adding another feature to a list. It was about looking at the places where a database client can make everyday work unnecessarily difficult—or unnecessarily risky.

When building a database client, it's tempting to think most of the work is going to be around SQL execution.

It isn't.

Running a query is relatively straightforward.

The harder problems start happening around the query.

What database am I connected to?

How do I understand an unfamiliar schema?

What happens if I accidentally run something against the wrong connection?

How much data am I about to pull into the application?

How do I edit a JSON value?

Which record does this foreign key actually refer to?

What happens if a query doesn't finish?

These are the problems we spent a lot of time thinking about while working on 1.1.0.

The first problem is usually understanding what you're looking at.

A database with ten tables is easy enough.

A database with a few hundred tables is a different story.

Opening tables one by one and following foreign keys works, but it isn't a particularly good way to understand a system.

So we built schema diagrams directly into DBO Studio.

The new diagram view can generate a visual representation of your database, automatically arrange tables, search through the schema, and export the result as PNG or SVG.

It also has a DBML representation, which means the diagram isn't just something that exists as a visual layer inside the application.

When you're working with an unfamiliar database, having that map available changes the workflow quite a bit.

Instead of reconstructing relationships from individual tables, you can start by looking at the structure of the database as a whole.

There is another problem that every database client has to deal with.

The application knows which connection you're using.

Your brain doesn't always do.

It's surprisingly easy to have a production connection open in one tab and a local database in another, then execute something without noticing.

A database client shouldn't prevent you from doing your work, but it should make expensive mistakes harder to make.

That's where Safe Mode came from.

In 1.1.0, Safe Mode can be configured independently for each connection.

You can choose different levels of protection for queries and writes, from no interruption to confirmation and password-protected operations.

The important part is that the policy belongs to the connection.

A local development database doesn't necessarily need the same level of protection as production.

For an additional layer of protection, DBO Studio also supports an application-wide Safe Mode password.

On supported platforms, protected operations can be unlocked using Touch ID, Face ID, or Windows Hello.

The goal isn't to put a confirmation dialog in front of everything.

It's to make the dangerous things noticeably harder to do by accident.

The data grid was another area where we kept running into the same problem.

A database isn't a spreadsheet.

A boolean isn't a string.

An enum isn't a string.

JSON isn't a string.

Geometry definitely isn't something you want to inspect as an unreadable blob of text.

So the data grid now understands more of the types coming back from the database.

Version 1.1.0 adds dedicated editors for boolean, enum, date/time, binary, JSON, and geometry values.

Foreign keys also get a more natural editing workflow with an autocomplete picker.

Instead of copying an ID from another table and pasting it into a cell, you can work with the relationship directly.

Geometry values can also be previewed from the cell value panel instead of having to interpret their raw representation yourself.

The grid also gained a set of context-menu actions for common operations such as filtering, sorting, hiding columns, copying values, setting NULL/empty/default values, and adding, duplicating, or deleting rows.

None of these changes are particularly interesting in isolation.

Together, they make the difference between a grid that happens to display database rows and one that is actually useful for working with them.

We also wanted to make query execution easier to control.

Long-running queries can now be cancelled withEsc, both from the SQL editor and the data grid.

And, as mentioned earlier, unbounded SELECT queries are now paginated automatically.

The change is intentional.

SELECT *
FROM orders;

will no longer mean "fetch everything you can."

If you know that you want 500 rows, make that explicit:

SELECT *
FROM orders
LIMIT 500;

In 1.1.0, an unbounded SELECT fetches 100 rows at a time, with a hard ceiling of 10,000 rows.

Show the SQL editor and the resulting paginated data grid. This should make the new behavior immediately understandable.

This is a breaking change.

We considered keeping the old behavior because it is familiar. In the end, we preferred a safer default.

Database tools have enough ways to surprise you already.

Fetching millions of rows because a LIMIT was forgotten shouldn't be one of them.

Another small but important change is connection diagnostics.

Test Connection now reports additional information, including latency, server version, and SSL status.

Connection errors have also been categorized and improved to make them more actionable.

This matters because the problem isn't necessarily in the client.

It might be TLS.

It might be authentication.

It might be the server.

It might be the network.

The more information the client can give you, the less time you spend guessing.

PostgreSQL and MySQL connections also now have more explicit SSL/TLS modes and certificate options, making it easier to work with environments where encrypted connections are required.

Not everything in 1.1.0 is visible in the UI.

We've expanded our Playwright coverage so the same end-to-end workflows can run against PostgreSQL, MySQL, and SQLite.

We've also added typed mappings for query results, including enums, binary values, geometry, and related columns.

On the desktop side, the application now has a native menu, a boot splash, and improved lifecycle management for the backend sidecar.

We've also added a searchable keyboard-shortcut cheat sheet to Settings.

These aren't particularly exciting things to put in a screenshot.

They are, however, the things that become increasingly important as the application gets larger.

A database client has to be predictable before it can be powerful.

1.1.0 also fixes several issues around typed data editing and query lifecycle management.

We've improved editing for enum, boolean, datetime, binary, and geometry values, and fixed an issue where in-flight queries could remain active when switching tabs.

Some of these fixes are small from a user's perspective.

They matter because database tools are often used for tasks where a small inconsistency can become a much bigger problem.

Looking back, 1.1.0 wasn't really about adding a list of features.

It was about removing a few classes of uncertainty.

What does this database look like?

Schema diagrams.

What happens if I run the wrong operation?

Safe Mode.

What exactly am I editing?

Typed data editors and foreign-key autocomplete.

How much data am I fetching?

Pagination and result limits.

Can I stop this query?

Esc.

Why can't I connect?

Better diagnostics.

Those are small questions individually.

They're also the questions that tend to interrupt you when you're working with a database every day.

That's what we wanted to improve with DBO Studio 1.1.0.

And there is still a lot left to improve.

We're building DBO Studio around the database workflows we actually care about: understanding data, querying it, editing it, and doing all of that without making the easy mistakes unnecessarily expensive.

DBO Studio 1.1.0 is available now.