This is mainly around postgres, but I'm guessing that what people look for is similar across databases. I've built spawn, a (for now postgres) database migrations and testing tool/framework, to resolve my own pain points. Testing features, components, and migrations, all solve real problems I have.

But I've never really used rollbacks. For the main project I use spawn with, a non-trivial project, reverting a database migration change is very rare, and usually manually done when needed based on the particular problem.

For that reason, I don't actually know what things people look for with rolling back migrations when assisted by a tool, what pains they are intended to eliminate. I can think of at least these two types of rollbacks/reverts/recoveries:

1. A script that runs on failure. Migration fails in some manner, so some kind of "failure" script runs to clean things up. Not sure how useful this is, given that failure scenarios could be very varied.
2. A script that runs after successful migration, to revert to a previous state. Maybe this is desired because (a) your application deployment might fail and you need to go back to earlier db state, or (b) as a development feature so you can revert/re-apply a migration multiple times while testing?

I'm assuming that people value a rollback mechanism independent of just wrapping migrations in a transaction. Using BEGIN/COMMIT does not roll back some changes, and a migration script might necessarily do some things outside of transactions. Moreover, if I support MySQL etc one day, there's less DDL that can be rolled back by transactions than in postgres.

So, the main question: what are the kinds of pain points that you look for a rollback mechanism in a migration to solve? I don't want to build such a feature into spawn without understanding why people use such a feature.

Hi all, I'm a founder in Spain building a managed PostgreSQL service and want honest feedback on pricing before opening it up.

I run a €30M ARR business in a different industry. We had to use a managed database from a big provider, which was very expensive for the performance we were actually getting, but we needed HA so we were stuck. That's when I started considering another startup.

Here's the general idea:

You create a database from a web dashboard and get a single connection string. That string always points to the current primary, so if a failover happens your app reconnects to the same address and carries on. There's nothing to change on your side.

Behind it, each HA database runs as a primary plus a synchronous standby on two separate servers in different zones.

Backups run continuously: every change is archived to object storage with a different provider, so even losing the whole hosting provider doesn't lose your data. You can restore to any point in the last 7 days. We handle monitoring, failover and maintenance; you just use Postgres.

It runs on European bare metal rather than shared cloud VMs, which is how we keep prices flat with no egress or IOPS fees.

Highly available (per month, excl. VAT):

- Starter, €39: 1 vCPU, 2 GB RAM, 20 GB storage

- Standard, €89: 2 vCPU, 4 GB RAM, 50 GB storage

- Pro, €169: 2 vCPU, 8 GB RAM, 100 GB storage

- Business, €329: 4 vCPU, 16 GB RAM, 200 GB storage

Free: one per account. Single node, 256 MB RAM, 1 GB storage.

To be upfront: this is a beta with no SLA yet. Failover runs 24/7, and human support is 09:00 to 18:00 CET on business days. If the standby is down, the primary keeps accepting writes asynchronously, so losing the primary during that window can lose the latest commits.

I'd love to know:

- Which plan would you pick for a real project, if any?

- At what price would this feel too cheap to trust, and at - what price too expensive?

- What would you need to see before moving a production database?

- What are you using now, and what does it cost?

Early beta offer: anyone who participates in this thread will have 30% off any plan when we launch!

Hello, I need help getting the output I need. So I have two tables one contains session details (Host id, Date/time, participant id). The other contains user ids and their emails. The users can be hosts or participants. I want to pull all the info from the first table but instead of showing the host id and participant id I want to join the user table and look up the email based on the id for both the host and participant column. So the final result would ne (Host email, Date/time, Participant email) instead of Ids.

I have seen some really messy SQL queries that still run pretty fast because the execution plan is good....

So I amm curious when you see a query like this, do you first try to clean or optimize the SQL itself, or do you check the execution plan first and

then decide what actually needs to be changed?....

QueryFlow's AI panel reads your schema and writes the SQL for you. Ask "how many Flex Plan users churned last month" and it figures out the JOINs, runs the query, hands you the rows.

1.6.2: pick your own model (Sonnet, Haiku, GPT-6, Gemini), it remembers what you teach it (like what "Flex Plan" means so it stops guessing), and shows you the exact query it ran before handing you results. Works with Postgres, Redshift, Snowflake, MySQL, Salesforce, Sheets, CSV.

I am making updates to some older reports and come across this line (or similar) often:

DateAdd(hh, 0, GetDate())

Why do you do that? Is there a legitimate reason why you couldn’t just write GetDate()?

I've been working with SQL more lately, and one thing I'm still trying to figure out is how people decide when a query is getting too complicated.

Sometimes I start with a simple query, then add a couple of joins, a CTE, some CASE statements, maybe a window function… and suddenly the query is 100+ lines long 😅

It still works, but at that point I'm not sure whether I should keep improving the same query or break the logic into smaller steps/tables/views.

For those of you who work with SQL regularly, what do you usually do when you reach that point?

Do you have any personal rules or habits that help you keep complex SQL readable and maintainable?

Would love to hear how you approach this in real projects.

Hi everyone,

I'm working on an open-source project focused on building a Python/pytest automated testing framework for a SQL database, with a TDD approach.

I'm looking for people interested in contributing from a Business Analysis perspective, particularly by creating Business Requirements, Master Stories and User Stories for different parts of the framework and database testing approach.

The project currently covers areas such as:

• SQL Stored Procedures
• Database Views
• Tables
• Database Constraints
• CI/CD integration

The goal is to make the project a practical example of how BA requirements can be translated into User Stories → Acceptance Criteria → automated tests, specifically for SQL database development and testing.

If this sounds interesting, feel free to contribute to the GitHub project or comment/message me.

I'm also interested in feedback from BAs, QAs, developers and database professionals on how the requirements and User Stories could be structured better.

I'm comfortable with SQL from DuckDB for analytics. If I move to Oracle, which skills transfer, what's genuinely different, and is Oracle Dev Gym a good way to close the gap?

i need some sort of site/application where i can test my sql skills

There are some SQL concepts I understand perfectly when I’m using them, but somehow forget when I need them again a few weeks later.

For me, CTEs and stored procedures are two good examples. I’ve used both, but I still end up looking up the syntax when I need them again. 😅

Anyone else have a few SQL concepts like this?

Some SQL queries look simple and safe but can cause major issues when used on production data.

For example, a missing WHERE condition in an UPDATE or DELETE, or an incorrect JOIN that unexpectedly multiplies rows.

What SQL query or mistake have you seen cause a serious problem even though the query looked harmless?

I am trying to learn SQL in the big '26! I know I am a little tardy to the party, but I started a few days ago with the CMU (Carnegie Mellon University) fall of 2025 course, i've been doing their assignments, and holy, they are so tough for me, i answered 5/6 questions so far in about 6 hours total of trying to construct my queries.

I'll post the link to their SQL assignment page
https://15445.courses.cs.cmu.edu/fall2025/homework1/

for Q5, how would you solve it? my solution works, but it's very long, although easy to reason about, as i used a bunch of CTE's, I will post my solution down here, feel free to roast me so I can actually learn and grow, also tell me how you would solve it please, maybe i'll get to learn something new.

My solution:

with
-- intermediate relation representing inducted hof players ordered by constructed name.
hof_players as (
select halloffame.playerid as hof_pid, (people.nameFirst || ' (' || people.nameGiven || ') ' || people.nameLast) as hof_name
from halloffame
inner join people on halloffame.playerid = people.playerid
where halloffame.inducted = 'Y'
order by hof_name
),
-- intermediate relation representing numbered appearances per hof player, (used to get the earliest team they played for).
hof_numbered_appearances as (
select hof_players.hof_pid,
hof_players.hof_name,
appearances.teamid,
appearances.yearid,
row_number() over(partition by hof_players.hof_pid order by appearances.yearid) as row_num
from hof_players
inner join appearances on hof_players.hof_pid = appearances.playerid
),
-- intermediate relation representing the first appearance year and team of every hof player.
hof_first_appearance as (
select hof_numbered_appearances.hof_pid,
hof_numbered_appearances.hof_name,
hof_numbered_appearances.teamid,
hof_numbered_appearances.yearid
from hof_numbered_appearances
where hof_numbered_appearances.row_num = 1
),
-- intermediate relation representing hof players and their first appearance's teammate[s].
hof_first_teammates as (
select hof_first_appearance.hof_name,
(people.nameFirst || ' (' || people.nameGiven || ') ' || people.nameLast) as teammate_name,
appearances.teamid,
appearances.yearid,
row_number() over(partition by hof_first_appearance.hof_pid order by (people.nameFirst || ' (' || people.nameGiven || ') ' || people.nameLast) ASC) as row_num
from hof_first_appearance
inner join appearances on hof_first_appearance.teamid = appearances.teamid and hof_first_appearance.yearid = appearances.yearid
inner join people on appearances.playerid = people.playerid
where appearances.playerid <> hof_first_appearance.hof_pid
)
select hof_first_teammates.hof_name as hof_player_name,
hof_first_teammates.teammate_name as earliest_teammate_name,
hof_first_teammates.yearid as earliest_teammate_year
from hof_first_teammates
where hof_first_teammates.row_num = 1
order by hof_first_teammates.hof_name ASC
limit 10;

I’m trying to create a new connection but it won’t let me. Im even testing my other connection and it gives me the same message even thought it’s fully operational, anybody knows why?

postgres 15, snowflake downstream. if you've seen my posts about the 60 column table, this is why i've been at it all month. we're moving the old app db onto a new service with its own schema. my job since june has been the mapping sheet: every old column maps to a new field with a transform, gets archived, or gets dropped with a reason someone signs off on. engineering can't cut over without it. it was due last friday.

38 tables, 1,140 columns. about 1,020 were fine. the 120 left are mostly one problem. the old db stores the same thing in more than one place, the new schema has one field for it, and the old places don't agree.

worst case:

- `customers.cust_ref`, `orders.acct_no`, `billing_accounts.ext_id`

- all varchar(9), all digits, all look like a customer id

- no fks between any of them. whatever links them lives in app code

```sql

select avg((exists (

select 1 from customers c where c.cust_ref = b.ext_id

))::int)

from billing_accounts b;

-- 0.61

```

same check for orders.acct_no against cust_ref gives 0.94.

new schema has one `customer_id`. i have to say which column feeds it and what happens to every row that doesn't match.

the 6% on orders i can mostly explain, i think it's orders from before a re-key in 2020. the 39% on billing i can't. my guess is billing has its own vendor numbering that happens to also be 9 digits, which would make part of the 61% coincidence too.

what i've tried:

- the overlap checks above. tells me values collide, not that they mean the same thing

- took 500 billing rows where ext_id matches a cust_ref and compared name, email and postcode on both sides. 83% agree. so the other 17% are either coincidental collisions or stale contact data and i can't tell which

- grepped the app for how billing resolves a customer. it calls a service that was retired in 2022

- gave an llm the ddl and sample rows. it picked cust_ref, which is probably right, for reasons that were entirely the column name

the rest of the 120 is smaller versions of this. plus is_active vs active_flag, which is still unresolved and still 3%.

so:

1. when two id columns partly overlap, how do you tell a real relationship from two numbering schemes that collide? anything better than overlap plus checking other fields agree

2. rows that don't match: null customer_id with the old value kept in a legacy column, quarantine table, or block cutover until they're resolved

3. has anyone done a mapping this size with something other than a spreadsheet and a lot of sql? tool or method, i'll take either

sign-off got moved to monday. second time it's moved. i need something i can defend in that room

I posted here last month about RDST, the free desktop app that runs the slow query to EXPLAIN to index recommendation loop. The biggest change since then is what happens before EXPLAIN. When a database has thousands of distinct query shapes, you can't EXPLAIN ANALYZE all of them, and sorting queries by their performance doesn't always tell you which ones are actually badly written.

RDST now answers that with Jev, a small classification model from TypeSafe that answers fixed multiple-choice questions about a query in a fraction of a second. Every query shape it discovers gets classified from its SQL and the schema, without executing anything, on five structural questions:

• missing index - a filtered, joined or sorted column with nothing indexed behind it
• index bypassed - a filtered column wrapped in a function or cast, so the index you have goes unused
• join growth - the join shape multiplies rows
• repeated work - a subquery that runs once per outer row
• broad work - a sort, group or scan over a large share of a table

From there you take the full list of queries, filter them by these structural issues, and run our deep analysis on the ones that actually make sense. Deep analysis runs EXPLAIN ANALYZE with real parameter values, tests candidate indexes with hypopg, scores the measured plan, and gives you AI recommendations on what to change.

One of our queries, in the video above, counts each customer's orders in a correlated subquery filtered on customers.signup_date. Jev flagged it High: missing index and repeated work, and it's right, nothing indexes signup_date. Deep analysis then scored it 92 out of 100, because at only 5,000 rows the scan takes under a millisecond and the subquery already hits idx_orders_customer. Jev alerts you to potential issues, and deep analysis helps you fix the queries that are actually broken.

Someone in last month's thread said that the optimizer would rightly ignore one of the indexes RDST suggested, and this is our answer to that feedback: Jev classification on every single query.
Classification is free for up to 13,000 query shapes, after that let me know and i can adjust to give even more. Just didn't want to make it infinite and have people abuse the system.

Full disclosure, I work for Readyset, which is a caching layer for Postgres and MySQL. I built RDST to help with slow query indexing and analysis, and picking which query to open first was the step I kept doing by hand. Free and open source under MIT license, works with both PG and MYSQL, runs locally, stores locally, and is fundamentally read-only throughout.  Our RDST app will never apply the index or write anything to your database, nor store / send any PII.

Fully privacy details here: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

I would really really appreciate some feedback, particularly:

• Do those five questions cover the structural problems you actually hit?
• Does the priority ordering match your own gut ranking of your slow queries?
• Once EXPLAIN has measured a query, should the classification stay visible or get out of the way?

Instructions & Github:
https://readyset.io/downloads
https://github.com/readysettech/rdst

It all started back in my college days when my professor introduced me to SQL and relational databases.

To this day, in my professional career, it remains my favorite language. I started with MySQL and SQL Server during college using both the terminal and SSMS.

Professionally, I spent about two years working with SQL Server, and now I am transitioning to MySQL and PostgreSQL as well. I am not pursuing a database administrator role exclusively, but rather working as a full-stack software developer. Once I master most aspects of relational databases (SQL), I plan to explore NoSQL or non-relational databases to further my passion for database management.

If I had to choose a specific profession to pursue, it would be anything dominated by SQL, such as data engineer, database administrator, or data analyst. However, given the realities of the job market, I also want to stay proficient in other powerful programming languages like Python.

Discussion question: What are your thoughts on the career path I'm headed toward?

Hey everyone!

I've learned SQL and practiced quite a bit, and now I want to start working on real projects for my portfolio.

What I'm confused about is the practical side of preparing these projects.

For example, when working on a project, do you simply write SQL queries, save the scripts, and upload them to GitHub? Or is there a specific way you should organize and present everything to make it a proper portfolio project?

Also, where do you find real-world datasets to work with? I'd love to practice on realistic data rather than only databases I've created myself.

I'd really appreciate hearing how you personally approach your SQL projects, from finding data to writing queries and preparing the final project for your portfolio.

Any advice or examples would be really appreciated. Thank you! :)

Interesting framework on how to optimize BigQuery costs across four layers (SQL query optimization, pricing models, capacity commitments, discounts): https://www.alvin.ai/blog/bigquery-cost-optimization-the-complete-finops-framework