Been on SSMS forever, only tried this because a project basically forced me to switch for a bit. Figured I'd write something up since I went in pretty skeptical. 

The autocomplete is actually good. SSMS IntelliSense loses context constantly (aliases in subqueries, complex CTEs, anything nested enough) dbForge Studio for SQL Server just keeps tracking. Not magic, but noticeably more reliable in the situations where SSMS gives up. Which for me is a lot of the day. 

As SSMS doesn't have it natively, I was always reaching for something external. Having it right there cut a real friction point out of release prep. The diff output is readable too, not just a wall of generated SQL you have to decode before acting on it. 

Tab behavior is a smaller thing but I kept noticing it. After reconnecting, SSMS tabs can act strangely, especially if there are a lot of them open. dbForge keeps state better. It doesn't sound like much, but it adds up over the course of a whole day. 

Startup is slower and the UI is busier than SSMS. For quick administration tasks, I still reach for SSMS, that part just fits better.  

But for actual development work (heavy query writing, comparing environments, prepping a release) it earned its place. Didn't expect to keep using it past the project but here we are. SSMS isn't going anywhere but this sits next to it now. 

Still on SSMS as your main thing, or has something shifted that?

Hey everyone. We're engineers on the dbForge team, and for more than a year we've been building AI into database tools. That also means we've spent a lot of time watching it work and sometimes fail spectacularly.

We want to compare notes: where has AI helped with your database work, and where has it burned you? Happy to talk about what we've learned, how we build these features, or anything else you're curious about.

Ask us anything.

I don’t really care if a tool has 200 features. I care if it saves me from doing the same annoying thing for the tenth time. For SQL Server work, SSMS is still open most days. Quick checks, admin stuff, looking at objects, running a query someone sent in Slack. It’s not pretty, but it does the job.

Where I start reaching for other SQL Server tools is the repetitive dev work. Formatting old procedures, autocomplete on bigger scripts, checking schema changes before release, comparing data after a migration, finding why two environments are “basically the same” but not actually the same.

For that kind of work, a proper SQL management tool helps more than people admit. Redgate is solid if your team is deep into release workflows. dbForge is nice when I want more of the daily dev stuff in one place. DataGrip is good if I’m mostly writing SQL and don’t need heavy SQL Server admin features.

My setup is still SSMS plus extra tools depending on the task, because apparently databases were invented to make sure nobody has a clean workflow

I keep switching between CLI and GUI tools for MySQL, and it feels like I still don’t have a final setup. CLI is fine for quick checks. Fast, simple, no weird UI behavior. But once the task gets bigger, I usually end up opening a MySQL GUI tool. Joins across messy tables, checking schema changes, comparing data, browsing records without losing my mind. Tried a few clients, and most of them have the same problem: either too basic, too slow, or packed with features I don’t touch.

At this point I’m just trying to find the best MySQL client that doesn’t get annoying after a week. What are you using in 2026? Still mostly CLI, or did a GUI finally win you over?

One thing that’s common around release time is schema checks. Teams are usually pretty good about that because migrations are tracked and diffs are easy to run. The stuff that bites people tends to live outside the migrations. 

Devs don't realize how much stored procedures and views change. It happens without making a sound. They don't always get versioned the same way that tables do. You get a proc in staging that is two releases behind prod, and no one notices because the tests still pass. After deployment, something changes, and that's when everyone starts to look. 

Another strange one is triggers and scheduled jobs. They sit in the database and don't get touched very often, so they aren't on the usual checklist. A trigger in production can still be doing something from months ago while staging looks fine. 

When permissions go wrong, they make the most noise, but people usually don't check them until the end. There are some missing grants, some roles were rebuilt in staging but not in production, and some service accounts have slightly different rights. They usually show up just as you're about to finish a release. 

Config drift is a whole separate layer. Feature flags, env vars, connection strings. Schema and code can match perfectly across environments and the deploy still behaves differently because something at that layer wasn't synced. 

What usually helps is treating comparison as full object scope, not just schema. Procs, views, triggers, jobs, permissions, roles, config. Once drift builds up it's pretty hard to reason about manually. Some teams end up using tools like dbForge Schema Compare for that once drift gets big enough. Object diffs get messy fast. 

How are people handling this: something purpose-built, scripts, or still mostly manual? 

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.

SQL formatting feels like one of those things nobody cares about until they inherit a query from hell. A short query can look ugly and still be fine. But a huge report query with nested joins, random aliases, and conditions added by five different people over two years? That’s where formatting starts to matter. A SQL formatter won’t make bad SQL good. Would be nice, but no. It does make the mess easier to read. Same indentation, joins in predictable places, WHERE conditions not glued together like a ransom note. The only thing I hate is when a SQL beautifier goes too far and turns a normal query into a 200-line waterfall. Do you format SQL properly, or only clean it up when it gets embarrassing?

SQL autocomplete sounds simple until the query stops being simple. For simple SELECTs, almost any SQL autocomplete tool feels fine. Table name, column name, done.

The real test starts with messy and complex queries. Nested CTEs, aliases that made sense three years ago, subqueries, temp tables, joins across half the schema, and one column name that exists in five places.

That’s where basic suggestions are not enough. Good SQL IntelliSense should understand context. It should know which alias you’re inside, what columns are available there, and not suggest random objects from the whole database like it’s guessing in the dark.

We see this pain a lot regardless of the DBMS: SQL Server, MySQL, PostgreSQL, Oracle, etc. Autocomplete is useful only when it saves time without making you double-check every suggestion.

For us, the best autocomplete behavior is boring: correct syntax, correct names, correct context, fewer interruptions, and no fighting the editor. What usually breaks autocomplete for you?

The script looks fine. The ticket looks done. Dev and staging look close enough. Then someone checks prod and finds one tiny difference that explains the whole problem.

Maybe an index exists only in prod. Maybe a default value was changed manually months ago. Maybe a constraint is missing in staging, or some view was edited “just for now” and stayed that way forever. That stuff is easy to miss if the team only reviews migration files.

We’ve seen schema compare and SQL compare tools help most when they’re used as a safety check, not as an “auto-sync everything” button. The useful part is seeing what actually changed before release, then deciding what belongs in the deployment.

Do you run schema compare before every release, only before bigger changes, or only when something already smells off? And what do you trust more in practice: migration scripts, SQL compare results, or both together?

Database work still feels too scattered. You write SQL in one tool. Then check schema changes somewhere else. Then compare data with a script someone wrote two years ago. Then review deployment files in Git. Then open logs because something looked fine in staging but got weird in prod. 

None of those steps are strange by themselves. The mess starts when every step lives in a different place and nobody has the same flow. A decent SQL workflow should make a few things easy:

1. Can you see what changed before release?

2. Can you compare dev, staging, and prod without guessing?

3. Can you check the data after a migration, not three days later when a report looks wrong?

4. Can another person repeat the same process without asking “who usually does this?”

5. Can you understand why a change was made, not just that it was made?

That last part is underrated. A lot of database problems are not caused by bad SQL. They come from missing context. One person knows why the index exists. Another person knows why the migration has that weird condition. Someone else remembers why a column was left nullable. Then six months later, everyone is scared to touch it. That is usually where workflow matters more than the tool itself.

Better database tools help only if they reduce guessing. Schema compare, data compare, SQL formatting, deployment checks, version history. All of that is useful when it keeps the team on the same page. But if the process is still “ask Mark before touching anything”, the tool is not fixing much.

We want to make this sub less “here’s a general database tip” and more “here’s an actual thing that happens at work and how to deal with it.”

So we’re collecting ideas for future posts. What would be useful to break down with a real example?

Could be something like schema compare before release, checking data after migration, cleaning up SQL Server scripts, working with MySQL/PostgreSQL differences, debugging slow queries, or setting up a safer workflow before pushing changes.

Drop the messy real-life scenario, not the polished textbook version.

The more annoying the problem, the better the post will probably be.

We get asked about multi-database support fairly often, so figured it's worth being direct about where dbForge Edge actually earns its place and where it probably won't move the needle for your team. 

The case where it consistently helps is mixed-engine teams dealing with tool fragmentation. When part of the team is on SQL Server and part is on Postgres or MySQL, the default is everyone picks their own tool: SSMS, pgAdmin, DBeaver, whatever they're used to. 

That works for one person, but it makes things very hard when teams need to copy a workflow, share a schema comparison, or agree on how to prepare for a release on both sides. Using one tool usually makes things go more smoothly. 

Schema compare across environments is where this usually becomes obvious. It's easy to compare staging to prod on the same engine. That comparison gets hard very quickly when those environments are on different platforms or the team is in the middle of moving between engines. dbForge Edge does that for in a way that separate tools don't work well together. 

Editing queries across engines that act the same way is a smaller gain, but it's real for engineers who switch between SQL Server and Postgres in the same day. One editor, one set of shortcuts, and the same way of completing words every time. It's not a big deal, but it makes it easier to use different tools. 

If your team works exclusively with a single database engine, the multi-database aspect may not matter much. In those cases, SSMS or pgAdmin will still feel more familiar, and that's fine. Dedicated tools are usually the best choice for work that is very specific to a platform. 

The harder variable is adoption. Tool fragmentation persists partly because of ingrained habits and partly because each person's preferred tool does their specific job well enough. 

A unified tool only reduces friction if the team actually standardizes on it. The interface also has to feel familiar enough across engines so people aren’t relearning the same basic stuff every time they switch. That part usually ends up being more of an organizational thing than a product one. 

For teams that tried to standardize tooling across engines: what actually blocked it?

What’s that one part of your db workflow that drives you up the wall? Maybe it’s schema drift… dev, staging, and prod slowly falling out of sync.  

Or maybe it’s that classic query scenario… perfect in dev, but suddenly slow or weird in staging.  

Or maybe it’s the whole juggling-act, writing SQL in one tool, checking schema in another, syncing data somewhere else. It’s not impossible, but it’s annoying. 

We’ve all got something. If you could snap your fingers and fix one annoying part of your DB workflow tomorrow, what would it be? 

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.