Why We Built SaturnSQL

May 19, 2026 · By the SaturnSQL team

Two things happened in the last twelve months that made our minds up.

PopSQL announced it was shutting down. Years of saved queries, schedules, and shared workspaces, suddenly with an expiry date. The replacement options were either "the giant analytics platform that wants you to rebuild your stack on it" or "the lightweight desktop client that does nothing for your team."

A few months later, ThoughtSpot announced SeekWell would reach end of life on July 31, 2026. Same story, different product. SeekWell teams had built scheduled SQL pipelines into Google Sheets and Slack, and now had a deadline to migrate them somewhere else.

We watched both happen, talked to a lot of teams about what they actually wanted, and built SaturnSQL.

The category nobody is serving well

Look at the SQL editor market today and you see three buckets:

• Single-developer desktop clients — DBeaver, TablePlus, DataGrip. Excellent for individual work. Useless for sharing.
• Giant analytics platforms — Hex, Mode, Sigma, Looker. Powerful, expensive, and they want to be your whole BI layer. SQL is just one feature inside the platform.
• Notebook tools — Hex, Deepnote, Jupyter-flavored products. Lovely for one-off analysis. Not where you keep your scheduled production queries.

And in the middle, the bucket PopSQL and SeekWell occupied: team SQL editors. Lightweight enough that your engineers, analysts, and data-curious PMs can all use them. Focused enough that they do not try to also be your dashboarding tool, your BI platform, and your data catalog.

That bucket is now empty. We are building it back.

What we keep, what we cut

We talked to dozens of teams about what worked in PopSQL and SeekWell, and what they would not miss.

Keeping:

• A browser-based editor with schema-aware autocomplete
• A shared query library, with folders and search, that everyone on the team can see
• Scheduled queries that deliver results to Google Sheets, where downstream pivot tables and dashboards already live
• Direct connections to PostgreSQL, MySQL/MariaDB, SQL Server, Redshift, and DynamoDB
• Real role-based access, not everyone needs to edit production queries

Cutting (for now):

• Trying to be a BI tool, no built-in charts or dashboards. Use Google Sheets, Looker Studio, or your existing tool of choice.
• BigQuery and Snowflake (on the roadmap, not at launch)
• Direct Slack delivery (also roadmap; today there is a workaround via Google Sheets)
• Notebook-style narrative output, that is a different product

We would rather ship a focused tool than a half-finished platform. The features above will land in order based on what migrating teams actually need, not what looks good on a feature comparison chart.

The AI question

Every SQL editor in 2026 has to have an answer about AI. Ours is on the Pro plan: a schema-aware assistant that drafts SQL from English, explains queries, and suggests rewrites. It uses your real table and column names, but it never sees your row-level data.

The honest part: Pro is on the waitlist as of writing. We would rather ship it correctly than fast. AI in a SQL editor is genuinely useful when it is grounded in your schema; it is actively dangerous when it confidently writes a query against tables that do not exist.

For now, the free and Starter plans focus on the workflow that pays the bills: write SQL, save it, schedule it, share it. AI sits on top when it is ready.

What we owe migrating teams

We did not build SaturnSQL just to ride a wave. We built it because we watched teams panic about a shutdown deadline, hand-copy queries out of a doomed tool, and arrive at a new vendor with no plan. That should not be hard. Two short migration guides are live:

• Migrate from PopSQL to SaturnSQL
• Migrate from SeekWell to SaturnSQL

Both walk through the same pattern: inventory what you have, export the SQL, recreate it here, run both old and new in parallel for a week, then switch over. For most teams it is a 30-minute job, not a six-week project.

What we believe about SQL editors

A few things we keep coming back to:

• SQL is not going away. Every BI tool, every "modern data stack" pitch, every AI agent that promises to free you from writing queries, still runs SQL underneath. The honest editors are the ones that do not pretend otherwise.
• A team SQL editor is mostly about sharing. Individual editors are a solved problem. The hard part is: where does the team's SQL live, who can change it, and how do you know who broke the dashboard last Tuesday?
• Boring infrastructure is good infrastructure. Schedules that run when they should, exports that land where they should, credentials that stay encrypted. We will spend more effort on these than on any AI feature.
• Honesty about the roadmap is a feature. We will tell you what is shipped, what is on the waitlist, and what we are not building. Other vendors' comparison pages will keep claiming we do not have features. Read this site instead.

What is next

In the months ahead, the priorities are: more migrating teams onboarded smoothly, Pro plan launch with the AI assistant and version history, and the BigQuery and Snowflake connectors that we keep getting asked for.

If you are running into the PopSQL or SeekWell shutdown, get in touch. If you just want a team SQL editor that does the job, try the free plan. If you are skeptical about another SQL tool, fair enough, we would rather earn it than market our way in.

More posts will follow. We have opinions about scheduled queries, about AI in the editor, about the cost of being a small focused tool in a market full of platforms, and about why team SQL still matters in 2026. We will write them here.

Thanks for reading.

— The SaturnSQL team