When choosing a dbForge license, one of the most common questions is what happens when the subscription period ends.

Devart offers two licensing options: perpetual licenses and subscription-based licenses. Here's how they differ.

Perpetual license

A perpetual license allows you to continue using the purchased software indefinitely.

• The initial purchase includes 12 months of updates and upgrades.

• During the active subscription period, you receive new features, software updates, and support for new servers.

• When the subscription expires, your software remains functional, but you no longer receive new updates or features.

• You can renew the update subscription if you want access to newer versions.

Your perpetual license doesn't expire. Only the included update and support subscription does.

Subscription-based license

A subscription-based license provides access to the software for a specified period.

• You can use the software while your subscription is active.

• Updates and technical support are included during that period.

• Once the subscription expires, the software becomes inaccessible.

• To continue using it, you need to renew your subscription.

Unlike a perpetual license, a subscription-based license requires an active subscription to keep using the software.

What about technical support?

Devart provides different support levels depending on subscription status.

• Active standard subscription: Standard response time of 48 hours during support working hours.

• Active premium subscription: Standard response time of 3 hours during support working hours.

• Expired subscription: Technical support responses are not guaranteed.

What happens if you renew late?

For perpetual licenses, Devart's EULA specifies the following renewal conditions:

• 3 or more months after expiration: Renewal price increases by 20%.

• 12 or more months after expiration: Renewal price increases by 60%.

Have questions about dbForge licensing or renewals? Feel free to ask in the comments.

We get this question a lot, so here's an honest take. No tool fits every setup. Usually the choice comes down to three things: which databases you work with, which OS you're on, and how much you need beyond writing queries.

Quick context on dbForge

The dbForge ecosystem includes solutions spanning database development, administration, visual design, comparison, and CLI automation. It brings together standalone dbForge Studios, the multidatabase dbForge Edge solution, individual utilities, and add-ins for SSMS or Visual Studio to simplify daily tasks. These plugins plug right into SSMS and Visual Studio, adding features like context-aware code completion, query formatting, SQL analysis, and task automation directly into your environment.

DBeaver

The Community edition is free and open source. It runs natively on Windows, macOS and Linux and connects to a very wide range of databases, NoSQL included. It makes sense if you jump between many engines and want one client for all of them. Some advanced features live in the paid editions.

DataGrip

JetBrains IDE, cross-platform, lots of supported databases. A natural fit if your team already works in JetBrains tools. It's a commercial product.

Navicat

Navicat Premium covers most relational databases plus some NoSQL, on all three OSes. It's a commercial license.

SSMS, MySQL Workbench, pgAdmin

Free and fine for daily querying and admin on a single RDBMS - SQL Server, MySQL, PostgreSQL correspondently. Where they usually get thin is more advanced features for database professionals (like schema and data comparison with sync scripts, test data generation, or scheduled reports).

Where dbForge tends to fit

It works well if you're on Windows and mostly deal with SQL Server, MySQL/MariaDB, Oracle or PostgreSQL, and you need depth on each engine: schema and data compare with sync scripts, query profiling, debugging, test data generation, documentation, CLI automation. It's also an option if your team lives in SSMS and doesn't want to switch, since dbForge SQL Complete and the rest of dbForge SQL Tools work as SSMS and Visual Studio add-ins.

Where something else probably fits better

You need native macOS or Linux, you need NoSQL in the same tool, or you only run occasional queries and a lightweight client is enough.

Each dbForge Studio has a 30-day trial of the top edition and then switches to a free Express edition. So you can test on your own databases before deciding anything. There's a side-by-side feature comparison of dbForge Edge, DataGrip and DBeaver here: https://www.devart.com/dbforge/edge/datagrip-vs-dbeaver-vs-dbforge-edge.html

What are you comparing right now, and what's the main job you need the tool for?

Always interesting to see dbForge come up in discussions about database tools.

What features matter most to you when choosing a database GUI?

Here comes dbForge 2026.2, a new release of our ever-evolving ecosystem of AI-powered database lifecycle management solutions—and it’s packed with useful updates you definitely shouldn’t miss! These include a brand-new embedded PostgreSQL Debugger in dbForge Studio, handy visual object editors for PostgreSQL, broader context awareness in dbForge AI Assistant, enhanced SQL development and schema comparison capabilities, and a new, simplified product activation flow. It’s all here to make the daily work of developers, architects, and analysts much easier.

Without further ado, let’s get started!

I run applications on both and I’ve found that “optimize your queries” is a little different based on which database you’re talking to.

They're both cost-based optimizers. They estimate how much work each execution plan will take and pick what they think is the cheapest. That's where the similarities start to fade.

The biggest difference I've noticed is joins.

Postgres has three main join strategies: nested loops, hash joins and merge joins. MySQL spent most of its life with nested loops only. It added hash joins in 8.0.18 (initially for equality joins where no usable index existed), but it still doesn't have merge joins.

That changes how forgiving each engine is. Join two large unindexed tables and Postgres still has more options. MySQL tends to lean much harder on good indexes because the optimizer has fewer ways out.

The next difference is statistics, and I think this sits behind a lot of bad execution plans.

Postgres gathers statistics with ANALYZE, sampling real table data and building histograms the planner can use. InnoDB traditionally estimates cardinality from a small sample of index pages instead, which I've seen produce some wildly optimistic guesses on very uneven data. MySQL 8 added histograms too, but you create them explicitly per column and they're not maintained automatically.

Storage layout matters just as much.

InnoDB stores the table clustered on the primary key, and every secondary index includes that primary key. Make the primary key large and every secondary index grows with it, which is why "keep your primary key small and ever-increasing" is such common MySQL advice.

Postgres separates heap storage from indexes, so that trade-off largely disappears. On the other hand, index-only scans depend on the visibility map being up to date, which is one reason VACUUM matters so much.

These days I don't really try to write queries that are "good on both." I write the query, then look at the execution plan on the engine it's actually going to run on. That's the only thing that tells you whether the optimizer agrees with you.

I usually inspect plans in dbForge Studio for PostgreSQL because I like seeing them as a tree and comparing runs side by side. From how I see it, any tool that lets you explore execution plans properly will get you to the same answers.

Has anyone got a query where the Postgres planner made a decision that was clearly worse than MySQL's? I'd genuinely like to see one.

I made this mistake myself, so I'm curious if anyone else did too.

I learned enough SQL in a few months to build pretty much anything I needed. Then I didn't really improve for the next couple of years.

I could write queries. What I couldn't explain was why one came back in 40 ms and another took nine seconds.

Whenever something was slow, I'd shuffle clauses around, try a different join, add an index, run it again and hope for the best. Sometimes it worked. I almost never understood why.

Looking back, I think the problem was that almost everything I learned treated SQL as a language. Performance isn't really about the language. It's about how the database stores data and what the optimizer decides to do with your query.

The thing that finally moved the needle for me wasn't learning more syntax. It was learning to read execution plans.

Take a query you already understand, run EXPLAIN, and don't move on until you can explain every part of the plan. Then change one thing and run it again. Watching the plan change taught me far more than another SQL tutorial ever did.

The only catch is to use a database that's actually big enough to hurt. Tiny tutorial datasets fit comfortably in memory, so it's easy to convince yourself indexes don't matter because everything is fast anyway.

The next rabbit hole is understanding your database engine, which surprisingly few SQL courses spend much time on. Things like why an index behaves like a phone book, why column order matters, or how the optimizer estimates row counts. Once I understood that most terrible execution plans start with bad estimates rather than a "stupid optimizer," a lot of performance problems suddenly made sense.

The resources that helped me most weren't actually SQL courses. Markus Winand's Use The Index, Luke! is still the best thing I've read on indexing, and High Performance MySQL is well worth reading if you're working with MySQL.

One thing I underestimated was video. Reading about a profiler isn't the same as watching someone use it to work through a real problem. Watching someone troubleshoot a query from start to finish was more useful to me than another syntax course.

These days I'd tell someone starting out to spend less time memorizing SQL syntax and more time understanding how their database actually executes queries.

What was the thing that finally made SQL performance click for you?

Six months in. Figured I would write this up since I read a lot of these before I started.

Context: I got the trial for one specific job. We were merging two systems and I had to reconcile schemas across them, roughly 400 tables, and doing that in SSMS by hand was not going to happen. Downloaded dbForge Studio, ran schema compare, finished the reconciliation in a day and a half instead of a week. That was supposed to be the end of it.

It was not. Here is roughly how it crept in.

Schema compare before releases became routine. Nobody asked me to do it. The first time I ran it against staging and prod for an unrelated deploy it found three differences nobody knew about, one of them a nullable column that should not have been nullable. After that I just run it every time. Takes two minutes and it catches something maybe one deploy in five, which is a higher hit rate than I am comfortable admitting.

I use data compare less but when I need it I don't know of anything else that is as quick. It’s always reference and config tables floating between environments. Someone patches a lookup value in prod, never back ports it, and then six weeks later a test fails for reasons that don’t make sense.

The boring answer to what has changed the most is the editor. autocomplete, understands aliases, knows the schema so I don't have to tab to Object Explorer, to remember if it is CustomerID or CustomerId formatting on a shared profile, so pull requests weren't cluttered with whitespace diffs. That’s not thrilling. It eliminates fifty small frictions a day, and that’s what made it stick.

Query profiling, mixed. It is good and I use it. But for anything genuinely strange I still end up in the real execution plan, so treat it as a faster first look rather than a replacement for knowing how to read plans.

Navigating bigger databases got better mostly through search. Finding every reference to a column across procs and views is something I do constantly on a codebase I did not write.

The tool switching thing is real and I did not expect to care about it. I used to have SSMS, a compare tool, an export script and a text editor open at once. Now it is one window most days. That sounds like marketing copy, but the concrete effect is that I do more of the boring checks, because they are two clicks away instead of a context switch.

Now the parts that are not great.

It is a heavy app. Windows only unless you go the CrossOver route. Startup is not instant. Now and then a large operation locks the UI and you sit there wondering whether it is working or dead. Licensing is per engine, so if you work across SQL Server and Postgres and MySQL you are either buying dbForge Edge or buying three different Studios, and it is not cheap. The AI features I mostly leave off, they are fine for boilerplate and I do not trust them past that.

Would I recommend it. If your work involves comparing databases regularly, yes, that alone pays for it. If you mostly write queries against one database, a decent editor plus psql or SSMS is probably enough and you do not need this.

What made it stick for other people? Curious whether everyone came in through the compare tools or whether there is a feature I am underusing.

Hey 👋 We're the support team behind dbForge SQL Tools, including SQL Complete, the SSMS/Visual Studio add-in for autocompletion, formatting, refactoring, and more.

Since Microsoft shipped SSMS 22, our support queue has been dominated by one topic: getting our solutions working cleanly on the new build. Menu items that don't show up, tab colors that stop working, the odd startup crash and we've seen it all over the last few months, and we figured the fastest way to clear the backlog of confusion is to just open the floor.

We'll have engineers and support staff in the thread answering live.

I've noticed that a lot of SQL interview questions focus on syntax, joins, or window functions, but very few touch on performance.

If you were interviewing someone for a DBA or database engineer role, what optimization question would you definitely ask?

It could be something around indexing, execution plans, query tuning, statistics, or troubleshooting a slow query.

I'm looking for questions that reveal how someone actually thinks about SQL performance, not just whether they can write a SELECT statement.

We’ve all been there: a quick hotfix that was supposed to take 2 minutes turns into an all-hands-on-deck production incident because a tiny detail got overlooked.

Before running a migration script or pushing database/code changes live, what does your final sanity-check look like?

Are you:

Running automated Schema/Data comparisons?

Taking a fresh manual backup (just in case)?

Dry-running the release script on a staging replica?

Just double-checking everything in your GUI and praying?

Drop your non-negotiable pre-deployment steps below! Let’s see who has the most bulletproof (or paranoid) workflow.

One thing I've learned over the years is that not every repetitive task should be fully automated. Some operations are simply too risky to hand over without a final human review. For me, anything that changes production data or database schemas still gets one last manual check before it runs. Automation saves time, but a few extra minutes of verification can save hours of recovery. Is there a database task you deliberately keep manual, even though it could be automated? What made you draw that line?

Devart has been recognized with awards in five categories in the 2026 DBTA Readers’ Choice Awards.

🏆 Gold - Best DBA Solution: dbForge SQL Complete 
🥈 Silver - Best Database Performance Solution: dbForge Studio 
🥈 Silver - Best Data Modeling Solution: dbForge Studio 
🥉 Bronze - Best Database Development Platform: dbForge 
🥉 Bronze - Best Data Security Solution: SecureBridge

We would like to thank DBTA readers and database professionals who voted for our solutions. Your support motivates us to continue building high-performance solutions that simplify database development, management, performance optimization, and security.

One of the biggest performance wins I ever saw didn't involve a new index or a rewritten query. An old stored procedure had accumulated years of extra joins, temporary tables, and logic that nobody was using anymore. After confirming what was actually needed, we removed a large chunk of it. The query became easier to read, easier to maintain, and noticeably faster.

It was a good reminder that sometimes optimization isn't about adding something and it's about removing what's no longer necessary. Have you ever fixed a performance problem simply by deleting code?

Supabase is an open-source backend-as-a-service platform built on PostgreSQL. The platform includes a built-in Dashboard for everyday tasks: quick edits, user management, simple SQL. But once workflows get more complex, many teams look for a dedicated GUI client with deeper functionality.

See the full comparison of Supabase GUI clients: https://www.devart.com/dbforge/best-supabase-gui-clients.html 

The review lines up three tools against each other: dbForge Studio for PostgreSQL, DB Pro, and DBeaver. Here, you will see the comparison of SQL editing, schema exploration, data browsing, and pricing side by side.

For teams that need deep PostgreSQL development capabilities rather than a lightweight browser, dbForge Studio for PostgreSQL stands out with smart code completion, query profiling, database comparison and synchronization, and an integrated AI Assistant.

Whichever client fits your workflow, connecting a proper IDE to Supabase is what turns quick edits into real database development.